• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

Exception Handling

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Could anyone tell me how we handle Exception between layers of code.
eg.,
Client prgm -->layer1 pgm --> layer2-->...-->BeanPrgm (Exception is raised here)
How do we handle the exception in the client?
thanks in advance .
-Bergin.
 
Ranch Hand
Posts: 187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Bergin Roy:
Could anyone tell me how we handle Exception between layers of code.
eg.,
Client prgm -->layer1 pgm --> layer2-->...-->BeanPrgm (Exception is raised here)
How do we handle the exception in the client?
thanks in advance .
-Bergin.


with try{}catch(){} ???
What I usually do is left the exception raise from the lower layer to the client, in the client I use a try catch to handle the exception and decide where to go from there ( retry, abort whatever )
 
Bergin Roy
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanx for the reply. but can u be more specific please?
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is your protocol between layers? If it's all just Java method calls, normal exceptions should be fine. If it's SOAP or RMI or remote EJB calls, you'll have to study how the protocol does things. Frinstance, all remote EJB methods have to throw RemoteException, so your client is already coded to handle that. You can throw and catch other exceptions in some protocols. If you're using raw sockets, you'll have to invent something serialize exceptions on the server and recognize them on the client.
In a past life, I did a remote EJB call and found that I could propagate exceptions to the client ok, but the stack trace was not serialized so it was lost. So we overrode the constructor in our own Exception class to store the stack trace in a simple serializable string. I also made a linked list of exceptions, so one layer could catch an exception and throw a new exception with a better description of what was going on. The chain kept all the lower level exceptions for debugging.
Any of that help?
[ November 03, 2003: Message edited by: Stan James ]
 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is one of the fundamental problems with checked exceptions in a lexically scoped world. Stan's advice is very useful and probably most often used.
But if you find yourself declaring "throws Exception" in your intermediate layers just to pass the exception from the bean to the client, you're probably just as well off using unchecked exceptions for this case: extend RuntimeException and put a note in your API documentation. Rod Johnson is very eloquent on this topic in his book, Expert one-on-one J2EE Design and Development). Logging the stacktrace from the bean/server reduces the necessity of serializing the stacktrace for the client.
Alternative B: for typical exceptions like "file not found" you can pass a "callback" argument to the bean with handlers for the typical exceptions (this works best when client and bean are on the same machine).
Alternative C: (like B but works across the net) make your return value a somewhat richer object {value, [exception, stacktrace], handler(clientObject)}. This allows you to propagate "warnings" as well, which the standard exception model does not. Your return object can be subclassed to add handlers for each case. When the client receives the return object it calls the return object's "handler" method (with the client itself as a parameter).
Alternative D: do everything you can to avoid propagating exceptions to the client. Except for a few obvious cases (misspelled file names, for example), most exceptions deep down in the server don't mean anything to the client. Better to log them on the server (as warnings) and factor your client code so that it knows how to handle the "null" return value intelligently. To continue with the file example: "File not found" is an exception to the server, but it's just information to the client (how often have you done a "dir" or "ls" to make sure that something you tried to delete actually did get deleted?). This should be Alternative A, but if your roundtrip cost is high, it becomes less attractive, since it may involve the client querying predicates on the bean/server either before or after the call to get more detailed information about possible failed calls.
 
author
Posts: 361
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Once upon a time in a layered world in Kansas City, I subclassed ye old RuntimeException (unchecked) and lo and behold, the middle tiers were blissfully ignorant of the whole mess.
 
brevity is the soul of wit - shakepeare. Tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!