makehumancommunity
Provide easily accessible error summary with context information
When a crash occurs as a result of a user operation, it'd be helpful if the user got help providing a good summary of what happened and under which circumstances. In the best of worlds, the user should be provided with a pre-written error report he/she could simply paste here on github.
Apologies if this comment diverts from the issue primary goal, but I'm deeply interested in learning more about your anticipated approach for this feature. My questions are purely out of curiosity and a desire to better understand your strategy.
Will your implementation vary based on whether the feature is triggered automatically post-crash or if a user manually decides to report an issue? I guess this latest option could encompass not only bugs but also feature requests.
In the event of a crash, do you intend to extract data from traceback such as bpy.app, bpy.context, etc. in order to report the error context?
Also, have you thought about using the pyperclip module or a similar tool to ease the user's task of copy-pasting bug information?
I'm exploring a similar feature implementation elsewhere, hence my inquiries. Any insights you could provide would be greatly beneficial. If my questions seem off-track, please excuse me - they stem from a genuine interest in the subject.
@ashledombos : My idea is a low-tech solution where any user-initiated operation is wrapped in a try/catch block. This is achieved by having an abstract base class for all UI operators, wrapping the execute() call. If an error is thrown, context information is gathered and posted both to the log and to an error report file in the logs directory. The report contains info about the crash as such (exception class, traceback), relevant system versions (blender, python, mpfb...), context info (selected object, object state...) and basic paths (the location of the relevant mpfb system files). Thus this will always happen, but is limited to unforeseen and unhandled exceptions. Whether the user wants to report the event or not is up to him.
At some point, there might be a button for easily finding the last error report, but I don't plan anything more advanced than that. I'll be very hesitant in relying on third part code, as having additional dependencies for an addon is very cumbersome in blender.
The limitation here is that it'll only cover user initiated operations, such as when the user clicks a button. That's the only place where it is reasonable to intercept and handle the errors and capture the context information.
There is also functionality for globally catching errors too, see lines 37-46 and 90-93 in https://github.com/makehumancommunity/mpfb2/blob/master/src/mpfb/init.py. This is disabled per default since it migh mess with other addons' error handling, but can be enabled in the preferences panel. It's mainly there to help debugging strange events in asychronous situations, and then by a developer rather than by an end user.
Anyway, the background of the functionality is in part a frustration with incomprehensible error reports posted in random youtube comments (along the lines of "it don't work! why?" with no additional context provided). The functionality discussed here won't help all that, but at least for crashes I can point at a first step towards providing a more understandable error report.
Another input is work towards hardening the completely unrelated systems at my daytime job. My experience from there is that having autogenerated and structured error reports helps immensely when users experience an error.
@joepal1976 Thank you for your detailed answer. I find your approach very reasonable and pragmatic.
This is good enough for now. At some point, on a rainy day when there is nothing else to do, the rest of the operators could be updated to use this.