(Looking back at my comment, I didn’t mean “halt execution”, I mean halt execution of that transaction so the application could continue cleanly).

So I think the pattern you’re actually using is just hiding the internal implementation of your message handler — which makes sense because the calling code has no interest in the specific implementation of each handler, so that shouldn’t be a part of that external interface.

Curious: is your “XYZHandlerException” a checked exception?

@Michael: absolutely — the checked reflection errors are annoying because that’s pretty much guaranteed to be programmer error, and the error just needs to bubble up to the top level and be reported. I have a simple reflection utility wrapper that basically just wraps those errors in an unchecked exception with good debugging detail if something does break.

@Litty: agreed, don’t show your user a big stack trace with all of your internal debugging info. They generally won’t get anything from that info, and it could be exploited. I generally have two error displays (talking webapps for the moment), one for development/testing (which shows all error info plus dumps the current request, session, cookies, etc. to the screen), and another for production (which just says there was an internal error that has been reported automatically, they can try again or contact technical support if it keeps happening).

@Tracy: I agree you shouldn’t have to think about exceptions in most of the code — generally they’d indicate a coding error, and should just halt execution, because something has failed. Put in “try-finally” blocks to make sure resources get cleaned up where needed and otherwise let exceptions bubble up. But what do you mean you wrap them at higher levels? Won’t they just reach the top and get trapped/logged/handled?

I vary in how I handle IO and database connection issues… IO in a client application probably should be checked, because actions that use IO will quite probably fail occasionally (the network is down, the file is locked by another process, etc.) and need to be handled better than just a generic error. On the server… I go back and forth. At the moment my webapps mostly have checked exceptions for database access, because they *do* get caught and wrapped (with all details of the query included) and to remind developers that resources must be cleaned up as part of error handling. That wrapper that’s rethrown could logically be unchecked, though.

@Riyad: No special libraries; I do have a set of standard error handling code & approaches that I reuse from project to project, but it’s hard to encapsulate that kind of thing into a separate utility. I used to have custom wrapper exceptions, until the JDK added that feature.

@Michael/Dimitris,
That is *exactly* what I was looking for and curious about. My gut told me that working with checked exceptions (atleast when I did it) drove me nuts, try-catching even the smallest operation was really slowing me down, because then you run into the situation where you need to decide how granular you want your try-catch and detailed handling to be and that can turn into an art-form or a nightmare just in and of itself.

@Litty/Tracy/Parth,
An even higher level take that I wasn’t considering but can be just as important: what to do with the exceptions. I appreciate you weighing in.

Now I suppose a followup question would be:

Does anyone have any favorite exception handling/logging libraries out there that fit their work flow like a glove?

I like to throw exceptions at the lower level and will track it in my calling code (using some DB status etc…which can be used to notify users etc.. ).Main thing is,we should log it so properly(in log and DB both if possible) that the developer/System Admin can track down the error easily while digging into the huge log file .Because i had been through this situation a lot more times, i know how important to track exceptions if you want to keep you app. running up.

I mostly use checked exceptions,and mostly use diff. statuses for my business logic processes which can give me a proper indication.

regards,
http://www.techlads.com

The theory is that exceptions, under normal circumstances, should not happen. If they do happen though, it should be justifiable to halt the execution flow. A good API should offer all its functionality without requiring a single try / catch around it.

I have since however, since changed to favour unchecked exceptions – but not in every case.

Being forced to catch a myriad of exceptions when you execute a reflective method call where you can’t really do anything to recover is just irritating.