You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Whenever an exception is thrown, or a message is logged (using logging.root) the function that caused it, its arguments, and an error message is manually put together via a format-spec. This is fucking horrible to maintain and there's some cases where they're inconsistent (or I missed some variables in my format-spec). This is because this sort of stuff is a real bitch to test (large project without unit-testing syndrome).
It'd be nice if there's some way to automatically determine these things at the time the exception is raised so that way this would be a little bit more manageable. Maybe this would have to be done by requiring all custom-exceptions include an argument with the function name and its parameters. Then one can look at the types defined by the "multicase" decorator and automatically output that part.
If it's possible to walk through the stack frame (similar to internal.interface.address.pframe), however, then this would be awesome because it could be made to be entirely automatic.
The text was updated successfully, but these errors were encountered:
Whenever an exception is thrown, or a message is logged (using
logging.root
) the function that caused it, its arguments, and an error message is manually put together via a format-spec. This is fucking horrible to maintain and there's some cases where they're inconsistent (or I missed some variables in my format-spec). This is because this sort of stuff is a real bitch to test (large project without unit-testing syndrome).It'd be nice if there's some way to automatically determine these things at the time the exception is raised so that way this would be a little bit more manageable. Maybe this would have to be done by requiring all custom-exceptions include an argument with the function name and its parameters. Then one can look at the types defined by the "multicase" decorator and automatically output that part.
If it's possible to walk through the stack frame (similar to
internal.interface.address.pframe
), however, then this would be awesome because it could be made to be entirely automatic.The text was updated successfully, but these errors were encountered: