Skip to content

Conversation

@tzanko-matev
Copy link
Contributor

  • We snapshot all variables at each step of the script
  • We don't step through internal Python code which is not associated with a real Python file, thus reducing significantly the size of the trace.

Copy link

@Ro6afF Ro6afF left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that failing to trace a frame/value is treated like a critical error that causes the execution of the traced program to fail. I think that this is not the desired behavior.

Logging the error and continuing seems like a better option to me.
Or alternatively recording some kind of error value in the trace is a good approach too.

@tzanko-matev
Copy link
Contributor Author

I don't know what is the right behavior. During development I want the code to fail whenever something unexpected happens. This is the fastest way to notice that there is a bug. I try to split error conditions in two types:

  • Getting to an invalid state due to wrong input or environment - those should be handled properly and a good error message should be sent to the user
  • Getting to an unexpected state due to an error or omission in the program logic - During development and testing those should crash as close to the source of the bug as possible in order to make the bugs visible. Can we ignore them during production deployment?

@tzanko-matev
Copy link
Contributor Author

I'm merging this. WIll implement better error handling in a separate PR

@tzanko-matev tzanko-matev merged commit 2c7bcef into main Oct 2, 2025
2 checks passed
@tzanko-matev tzanko-matev deleted the value-capture branch October 2, 2025 10:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants