Exception handling in web applications...

[Daniel Platon]

Hello all,

This is not really a problem, is more like an... issue. Nowadays everyone preaches "decoupling" - we should decouple business logic from business data, we should decouple business logic from web logic etc. Regarding the latter I had an interesting argument. Someone pointed out to me that is "not ok" to catch exceptions thrown from the business layer in some class from the web layer (e.g., it's "not ok" to catch exceptions from a business class into some struts Action class, or Spring controller class). Of course many "decoupling" fans would start saying this is an excellent idea (or not ) but to me it seems plain stupid. Java code is written around exceptions - you call methods, they throw exceptions - you catch exceptios - you put some message on the user screen.
I would like to read some opinions from you about this - how much can we decouple in order to keep the code simple and, in the same time, keep some level of "decoupleness" for flexibility.

Thank you very much and have a good day,
Dan

PS: I don't know if this is the best location for this post. If not, I kindly ask a moderator to move it. Thank you.

[David McCombs]

Whether you throw an exception or handle it in the method that caused it depends on the situation.

Why do some exceptions in API classes get thrown? Why do some get dealt with when they happen?

The web logic part may need to do something specific if a problem with the business logic occurs.

If a web server is creating a dynamic page and waiting for data from a database, but something goes wrong, does the "web logic" need to know about it? Probably. If you have everything decoupled so much, that every class or package or whatever is not dependent on anything but itself, how useful, maintainable and functional is it really going to be?

I think that Sun over did exceptions. There often caught exceptions where you never really care about them.

Just like it is possible and undesirable to have tightly coupled code, it is possible and undesirable to have too loosely coupled code. I think overusing patterns can lead to this. Some people think everything must follow an established pattern, even if a simpler solution would be more appropriate.

There are benefits and trade offs to everything you will do in programming. There is no one right answer, you have to weigh the benefits against the trade-offs for every situation.

Be wary of one size fits all "solutions".
[ April 21, 2007: Message edited by: David McCombs ]

[Daniel Platon]

Hello again,

This whole exception mechanism that David said Sun over did helps the programmer build a flexible, fault tolerant code. That is, if you know what happened (some file missing, a database connection not established, some xml being malformed) you can take corrective action and let the user know that _something_ happened and his/hers operation didn't complete succesfully.
My initial post was about avoiding the whole exception thing and use some other mechanisms to let the user know something happened, which I consider totally ... well, extreme. Exceptions are meant to be thrown. Of course, you need to do some degree of wrapping, that is not throwing all this SQLExceptions, IOExceptions, Exceptions etc but wrapping it into some SomethingBadHappenedException and throwing it to the web part so a message to the almighty user can be composed.

Thanks,
Dan

[David McCombs]

Quite often it really doesn't matter what went wrong, you can safely ignore it, yet you still have to either throw it and/or clutter your code with senseless try/catch blocks. A simple example is if you are running a thread in an infinite loop and you put the thread to sleep for a bit, rarely do I care if, nor ever seen for that matter, an InterruptedException gets thrown.

if you aren't familiar with Python, check out their exceptions, much better.

You could handle the exception at the point it occurs, and then return something that indicates an error. More of a C approach, simpler but that has its issues as well.

When I program in Java I usually use a simple custom exception class to handle all exception that get thrown. It keeps things cleaner and doesn't hide possibly important information

[Bear Bibeault]

In a web application, you should never catch execptions at all -- at least not those that need to propogate all the way out to the user and generate an "Oops, our server screwed up" type of message.

Rather, an error handling servlet (or servlets) are set up in the deployment descriptor to handle any expcetions that make their way through the code to the container.

The decoupling comes from the fact that your controller layer (Actions, if you are using Struts) never catches the execptions and Just let's them propogate through.

The only exceptions I ever handle are those like NumberFormatException or ResourceNotFound exceptions which don't propogate between layers and where I take some well-defined action upon the exception, and keep processing.

[Daniel Platon]

In a web application, you should never catch execptions at all

Now don't get me wrong, I don't catch every bit of exception. I only catch checked-exceptions like ParseException, NumberFormatException or platform specific exceptions like DfException (this one's from EMC Documentum). Other exceptions just fly through the layers into some custom as-best-as-I-can-user-friendly page

More of a C approach, simpler but that has its issues as well.

I think that would have more downfalls like having to retain error-codes and such. You still have to decide what you do with the error code, maybe that's something that the user has to know about.

So my conclusion is - use exceptions but don't over do it

Thanks a lot,
Dan