Koon Yue Lam wrote:
Hi !! I agree with all of you but still have a question. If my application is divided into a few layers, say:
Web <---> BizDelegate --- <---> EJB |__<--> DAO / server side program
My practice is catch all SQLException in DAO(s), but never throws
excepion from my DAO, all DAOs will return primitive, at least a
boolean to indicate the query is success or not
It is because there is nothing to do with the above layers when
something goes wrong in DB.
Not sure I follow your logic here. The exception is just a flagging mechanism, and as such is more reliable / harder to ignore than returning a boolean (although the start of this thread pointed out, it's not foolproof!). Whether the next layer can do anything about it is a different matter. In practice this is the part that most systems fall down on - having proper information available to the user, but you still need a sure way to know that _something_ needs doing.
However if every method have a try -- catch block, especially in EJB and DAO layers, it would become a speed lose.
My suggestion is to try a test case with both styles, and benchmark them. Given the performance hit with Java anyway I don't think you'll find a measurable difference. I don't think it's worth compromising stability / maintainability over. But see what the measurements indicate to you.
My practice is to catch
ALL kind of Exception in just BizDelegate, whenever an exception is
caught, it return some primitive to the above Web layer. Because the
data between Web and BizDelegate can be throught network, sending an
Exception would be much inefficient than just True of False.
How often are exceptions going to be thrown? Sending an exception should only happen in _exceptional_ circumstances, they are not part of the normal flow control. Just how fast does your system need to fail?!? :-)
The bottom line is, my Web layer doesn't need to know what going
wrong, it just need to know IS IT going wrong. Then forward to some
error pages, or maybe retry one more time.
The aspect that lets most exception based systems down IMHO is that the context information is not available or presented to the user in many cases. This is the hardest thing to get right with exceptions, and requires the most up-front thought to do a really good job. This is usually (from a users perspective) not "what went wrong" as much as "what was I trying to do, with what information, when something went wrong with aspect X".
If returning booleans helps you with that, fine. Well structured exception types and handlers is just as capable, with the advantage (stated above) that they're harder to accidentally ignore.
But it still can't suit to all situation, some methods in BizDelegate will thorws Exception of the type BizDelegateException. When the web layer can do something to the exception, BizDelegate will include the Exception thrown from under layer to the cause of BizDelegateException, then throw up to Web layer.
Is it sounds good ??
That's a typical approach; Java itself has moved more towards nested exceptions in recent versions. The trick still IMHO is how to get relevent user meaningful context available at the point where it's reported. In some ways, the further removed and isolated the reporting is from the sources of error the less easy it is without some effort, yet again lots of IMHO all through this.
Brett Connor
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
