On 5/3/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
On 5/3/06, Rick Reumann <[EMAIL PROTECTED]> wrote:
> I think I've read over most of the conventional wisdom that talks
> about how throwing aRuntimeExceptions are a bad idea, especially from
> within a catch in a finally block (at least IDEA is warning me about
> it:) But my question is it really 'that' bad?
Won't you lose your first RTE when you throw another one from finally block?
It's in the catch of the finally block, and even if I did lose it
wouldn't matter since my error was logged so I'll know what happened
well enough.
> Do I really want to have to wrap that with a try/catch or declare that
> it throws WhateverException? What does that really gain me?
I guess this is religion/style thing. I would never return SQLwhatever
exceptions to business/web layer, I would convert it.
Well the daos of course aren't in the web layer, but you bring up
another annoying thing about not using RTEs from a backend layer - you
end up now having to create other Exceptions to wrap things just so
your layer further up (like the web layer or even the service layer)
doesn't have to know about SQLExceptions. (ie more work and for what
gain?)
If situation is correctable, you should catch the exception somewhere,
where you can correct the situation (I don't know, you wanted to
update, but there is no such row, so you can automatically call insert
right away). In this case you might rethrow it as a specific
exception, like PersistentObjectNotFoundException.
Ok sure, yes this is what I've typically done but it's still the same
problem.. now you have to handle that all the way up the chain - which
I'm not against but I'm really not sure anymore what that really gains
me. (Also, I'm not talking about Exceptions that you would want to
handle or do something with.. I'm talking about Exceptions that mean
"something is seriously broken."
If situation is fatal, throw RTE and don't bother much to catch, the
thing blew up anyway.
right. That's what I'm doing now.
If this is a business-related exception (say, all new hires must be
single girls from 18 to 29 yr old), return checked business exception.
Well, I guess this situation arises if you have business rules in the
database.
Yup that make sense (...oh and so does the new hires demographic:).
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
