• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Exception propagation in layered applications

 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,
we are working on a large, layered application, and are currently thinking about the propagation of exceptions through the layers.
Lets consider three Layers A, B and C. A is e.g. the GUI, B is business logic and C ist the database adaptation. So, A is "above" B, which is "above" C.
We see the following alternatives:
1) Exceptions occurring in C may be propagated up to A, through B, without any nesting or conversion.
Advantages: Easy to implement, full context of error in A, full stacktrace for debugging.
Disadvantages: Too fine grained, may be technical exception which A cannot understand and/or handle (e.g. File not found -> useless for end user).
2) Every package has its own exception set, and exceptions from lower levels are nested inside package-specific exception. So, exception from C ist packed into a "C exception" which is sent to B, which packs (nests) it into "B exception" (possibly adding business context), which is then sent to A.
Advantages: Full business context, clean interfaces, exception always understandable by client layer.
Disadvantages: Lots of code to nest exceptions, may over-simplify important exceptions from lower levels, loss of information, loss of exact stacktrace.
Perhaps some of you who faced this design decision can give additional hints or explain how this was decided.
Thanks a lot in advance!!
Best regards, Theo
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm lazy about exceptions, and usually throw and catch Exception without subclassing. Mainly because I've rarely found a spot where I would do different things based on different caught exceptions. For a serious app, I would probably have a single MyAppException class.
I like chained exceptions for end-user applications. I worked on one framework that caught exceptions and reinterpreted them in the context of what we were trying to do. For example, a lowest level exception might be "database table corrupted". The layer above that catches that and throws a new one that says "unable to retrieve user profile data" and the layer above that throws "unable to log on". We chained the exceptions and added a "details" button to the error message box that would dump the whole chain and optionally mail it to support.
For my own utilities I often let exceptions bubble all the way out to main() and let Java display them. The stack trace is interesting to me, but would be very bad for an end-user app.
BTW: I did chaining on a distributed application, and had to save stack trace data as strings added to our custom Exception class, not references to standard Exceptions, because stack trace info was not serialized between environments. Java 1.4 added chained exceptions, but might lose all the interesting stuff over the wire.
 
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I usually have 2 kinds of exceptions
1. System level (Run time Exception)
2. Application exception
System level exception are thrown if there some configuration problem, resource connection problem and so on.
Application level exception are thrown when there is invalid input from the end user.
System level exceptions interpreted by the webserver to display a common error page which says "Contact administartor"
Application exceptions are displayed to the user For e.g: "Invalid user name"
Any Comments ?
Hari
 
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
For prevent loss of information & stacktrace, you could catch the exception, print the stacktrace & then package the exception into the package specific excpetion & then throw it.
 
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Does anyone have a good links to resources or books where I can find some sample code for Exception Propagation in a multi layered Projects ??

Thanks,
Pavan.
 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here is my 2 cents-

There are two types of Exceptions
Checked Exception or Compiler enforced exception
Unchecked Exception or Runtime Exception

Based on your design you might want to categorize your exceptions as either of these.

For example if you have a properties file in your application, it is a RuntimeException. Create an exception i.e. missingpropertiesfileexception that extends RuntimeException. So when you mask it throw it as a Compile time exception in your A layer asking them to notify IT department.

Similarly when there is a Runtime Exception that is not handled properly by your developer then shut the system down for the user and inform the development team imme.

Compile time exceptions are something that will be automatically handled by your development team. On another note if you are sharing your data across different domains or groups then in the facade layer throw a application exception that extends Exception object. This will be a cleaner interface.

Good articles to look forward are

http://www.javaworld.com/javaworld/jw-08-2000/jw-0818-exceptions.html
http://www-128.ibm.com/developerworks/java/library/j-jtp05254.html
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We've touched on the debate over checked vs unchecked exceptions many times since this thread started in 2003 (!) so it may be worth using the forum search on exceptions.

Ten years ago Java was unusual in the OO world in its use of checked exceptions. A fair number of people think they were a failed experiment and prefer to use unchecked exceptions. For example, I just made a little utility for my own use and converted all checked exceptions immediately to unchecked and let them bubble up and kill main(). The program stops on any error (not a normal requirement) and coughs up a stack trace. I have another system that converts and bubbles up to a convenient place to catch them and tell the user something useful.

Bruce Eckel's Thinking In Java has a great chapter on exceptions that covers some of this controversy. Check it out free online or buy the book.
 
Beauty is in the eye of the tiny ad.
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic