This week's book giveaway is in the OCAJP 8 forum.
We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line!
See this thread for details.
The moose likes Servlets and the fly likes Exception handling in web applications... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of OCA Java SE 8 Programmer I Study Guide this week in the OCAJP 8 forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "Exception handling in web applications..." Watch "Exception handling in web applications..." New topic

Exception handling in web applications...

Daniel Platon
Ranch Hand

Joined: Oct 10, 2005
Posts: 42
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,

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
Ranch Hand

Joined: Oct 17, 2006
Posts: 212
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 ]

"Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration."- Stan Kelly-Bootle
Daniel Platon
Ranch Hand

Joined: Oct 10, 2005
Posts: 42
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.

David McCombs
Ranch Hand

Joined: Oct 17, 2006
Posts: 212
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
Author and ninkuma

Joined: Jan 10, 2002
Posts: 63353

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.

[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Daniel Platon
Ranch Hand

Joined: Oct 10, 2005
Posts: 42
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,
I agree. Here's the link:
subject: Exception handling in web applications...
It's not a secret anymore!