Closed ZeroKnight closed 3 years ago
It's entirely possible that this can cause a feedback loop if an unhandled exception triggers inside a module's on_message
handler. Since the notification method for this whole idea is a message over a protocol, it is hard to detect and prevent this from cycling without adding some extra parameter to events that can be leveraged for detecting a cycle. While this might be a valid approach, I don't feel like designing and implementing the architecture neccessary to facilitate only a single, rather minute feature that makes use of it.
Closed for now, might revisit later.
ZeroBot should catch any exceptions not caught further down in the chain, raised from command and event handlers as a last-mile fallback. Caught exceptions should then be passed to protocol modules via a standard
Context
event handler for uncaught exceptions; it should display an error message suitable for the protocol similar toreply_command_result
. The exception traceback should still be logged viaself.logger.exception
. The message should only reflect that an exception was uncaught, and suggest checking logs; not the exception information, as it shouldn't be sent out into the public.This would be preferable to the current behavior, where ZeroBot appears to do nothing on the protocol end and an exception traceback has been written to stdout.
This event should probably have some kind of recursion detection, in case the uncaught exception event somehow raises an exception.If message sending is broken, then at least it won't be flooding a server.