• 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

Nested exceptions

 
Ranch Hand
Posts: 782
Python Chrome Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

The prevailing wisdom in my team is to *not* actually nest the exception classes and return it back to the client. Instead we construct the stack trace as a string and pass that back. I think we learnt that from Manning's Bitter EJB book which argues that, in a distributed environment (e.g. webservices, session beans), you don't want to couple the client to any concrete exception class. Is that good advice ?

Pho
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
See if this is what you're asking about ... In one app I wrote a MyException class that took another exception in the constructor and built a chain one to the next. We did stuff like:

Then a custom toString() or printStackTrace() could walk the chain and print information from all exceptions in the chain.

The first draft of this thing actually held a reference to the original exception. Then we tried it over a remote EJB call and found that the stack trace of the nested exception did not get serialized and sent over the wire. So we changed it to keep a String representation of the message and stacktrace instead of a real reference.

Is that your situation?
 
Pho Tek
Ranch Hand
Posts: 782
Python Chrome Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Exactly liked how you described it.
 
author
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Another potential problem with nested exceptions is the impact on bandwidth. There's an example in "Robust Java" where I propagated a simple SQLException forward to the Web tier of a J2EE application. In the natural process of nesting the base exception for transport, the exception picked up an additional 4kb of stack trace due to additional exceptions and code layers in the containers. Obviously, this could have serious performance implications if you had a frequently occuring application exception.

While I agree that it's important to avoid coupling between parts of an enterprise, there may be some cases where exceptions are an appropriate way to communicate errors. A client will still have be tightly coupled to its server if it has to interpret and act upon an error. If a client must translate a string and act on the error, you haven't done yourself any favors by converting the exception in the first place.

That said, you DO want to avoid exceptions that require a lot of analysis or interpretation from the client... for the same reasons expressed in "Bitter EJB".
 
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
Excellent point on coupling, Steve. All that stuff I did with stack traces was just to display messages, not to attempt to parse or understand the data at all. For certain exceptions we put up an error window with a short message and a "details" button. The details button displays the whole chain of stack traces. No end user would ever do that unless they were on the phone with a developer to diagnose a problem. We hope.

I didn't realize we had a guest author on board and started answering a bunch of exception questions. Glad to see we finally got you (the intended expert) on the thread!
 
Steve Stelting
author
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Stan,

Actually, I've really enjoyed reading the discussions! It's neat to see so much brainpower concentrated on one Web site. I really wish I had worked with the forum for about 6 months before I wrote "Robust Java". I'm sure all of you would have quickly singled in on some of the finer points that took me months to express... such is the wisdom of teams!

Steve
 
reply
    Bookmark Topic Watch Topic
  • New Topic