SQLExceptions in JDBCWorkflowStore
"Bill Schneider" <[email protected]>
| Newsgroups | gmane.comp.java.open-symphony.devel |
|---|---|
| Message-ID | <010f01c30f5c$edbeacd0$0f03a8c0@complexity> |
I notice that in most cases, SQLException in JDBCWorkflowStore is caught,
and logged with "return null." In may cases, this would cause a
NullPointerException in AbstractWorkflow, which would in turn throw an
InternalWorkflowException wrapping the NullPointerException instead of the
original SQLException.
IMO it would be better if JDBCWorkflowStore threw InternalWorkflowException
wrapping the SQLException. Is that a reasonable thing to do?
This raises another issue, though. There are lots of places where a generic
Exception is caught and replaced with an InternalWorkflowException. but if
the caught exception was already an InternalWorkflowException, then it will
be wrapped twice. Would it make sense for the InternalWorkflowException to
instead have a factory method
public InternalWorkflowException getInternalWorkflowException(Exception e) {
if (e instanceof InternalWorkflowException) {
return e;
} else {
return new InternalWorkflowException(e);
}
}
and use that universally instead of the constructor?
- Bill
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf