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?
For example let's say for an "updateSomething" behavior...
UpdateAction --> UpdateService ---> UpdateDao
Now currently I have an error file defined in my web.xml that is used
to display any nasty error that might have trickled up and out of
struts and notifies the user.
My updateDAO, which in my case uses iBATIS has to catch SqlExcptions,
but my point is why do I really care to propogate this error up the
chain with checked excpetions?
My service class might do...
update() {
dao.update(something);
}
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 don't
see what great advantage that gets me over doing this from my dao:
catch (SQLException se) {
log.error("Error in deleteProfile", se);
throw new RuntimeException("deleteProfile",se);
} finally {
try {
sqlMap.endTransaction();
} catch (SQLException se) {
log.error("Error in deleteProfile", se);
throw new RuntimeException("deleteProfile", se );
}
}
The point is my log will still show what went wrong, and it's ok the
app crashes at this point since it's something serious and I want it
to terminate. I'm not so sure why the layer above the dao needs to
worry about having to handle this Exception?
I'm guessin the theory is that if I were packaging this up and
providing it for some third party to use, I'd definitely want to throw
SQLException so the consumer is aware an Exception can occur and of
course they might not like a RuntimeException crashing their app if
things went wrong. I see the point in that, but I'm certain this a
case where the daos aren't going to be leaving this app. So in this
case, am I still crazy to be throwing a RuntimeException from this
dao? (I feel so dirty doing it, even though I think it makes the app
more clean:)
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
