OSWorkflow: new Exception handling

Good job on releasing 2.5!  I can finally release my code into production
know its backed by a production quality Workflow solution.

<<on soapbox>>
One thing I immediately noticed upon upgrading (I'd been using a 2.5
snapshot) was the changes in exception handling.  It seems like EVERYTHING
in Workflow throws a WorkflowException now. Furthermore, most the
implementing methods in AbstractWorkflow throw an additional StoreException!
If you're going to throw both exceptions, you should declare them in the
throws clause of the interface, not the implementation.

My general philosophy on exception handling is if the end user of an API
didn't do anything wrong (like pass null parameters, use invalid SQL syntax,
etc) and there are no exceptional circumstances that could come into play
(service not running on remote computer, etc), then the end user shouldn't
have to catch non-RuntimeExceptions.

For example, Workflow.getCurrentSteps(long id) throws StoreException.  Now,
why should the end user of the API care if the underlying workflow store
blows up while accessing the database (or whatever the backing store uses)?
If the store blew up, then the person who implemented that store needs to go
fix it. Fire up JIRA and create a new issue.  The end user just wants to
getCurrentSteps. If there are no current steps, then an empty List should be
returned (or null, its up to the developer).

Now, if the database itself was down entirely or the connection parameters
are wrong, its not the Store implementors fault. But if this was the case,
catching the StoreException would be pointless as the entire application
would be hosed anyways (no db). So for this special case, it would be better
to throw a RuntimeException that would bubble up to the view layer.

Finally, if WorkflowStore is going to throw StoreExceptions, the reason for
the throw should be declared in the javadocs. I'm assuming WorkflowStore
would throw a StoreException if there was an error querying/persisting
workflow steps.  Personally, I wouldn't have WorkflowStore throw anything.
But, if it must, I think AbstractWorkflow should catch those Exceptions and
log them or something. I mean, as an end user, what should I do if I get a
StoreException? Log it? There really is no means of recovery if the
WorkflowStore itself is blowing chunks.

What do you guys think? Maybe I'm totally missing something here.  Could you
please explain the rationale behind OSWorkflow's new Exception handling (or
lack thereof)?  Please don't take the post personally. I'm really anal about
Exception handling and the new version pushed a few buttons =)  ...good
thing Eclipse has a "surround with try/catch" fix button!
<<off soapbox>>

Thanks for all the hard work!
-nick dellamaggiore





-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01