theshoeshiner commented on PR #1156: URL: https://github.com/apache/commons-lang/pull/1156#issuecomment-1902690364
> > Conceptually there are two cases here: > > An expected, possible exception, usually checked > An unexpected exception, usually unchecked. > In the second case, the event listener absolutely should shut down, as should everything else. In the first case the exception needs to be handled. It's just a question of where and when. > > What an error listener might do is give devs the option to defer or relocate the normal error handling. It should also give devs the option to continue processing the other events if they're independent, or to abort processing if they're not. > OTOH suppose the events are very dependent — e.g. every event writes a record in a database and the credentials are wrong. I might want one try-catch to wrap and handle SQL exceptions from all invocations. In that case, maybe just don't install an error handler? That is, error handlers are for cases where events are independent, and normal processing for cases where they are dependent. Mostly agree. Though given that the main goal of the error listener would be to defer / relocate error handling as opposed to hiding it, is there really any reason to not allow providers the option to also separately handle unchecked exceptions? Setting the error handler (maybe a separate handler for unchecked?) is not much different than a standard catch block for unchecked exceptions, because at that point its up to the dev to make sure it's handled properly. Allowing two separate handlers doesn't seem like too much extra complication given that checked and unchecked exceptions are often handled by separate logic to begin with. So basically, all exceptions are initially caught by the invoker, with the caveat that they may be re-thrown if there are no handlers, causing the firing to stop. This implementation has the benefit that it would not affect any current users of this class, since I believe the absence of handlers should result in the class functioning exactly as it does now. Additionally there would still only be one fire() method, o that any current users that want to take advantage simply need to set the handler. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
