RE: OSWorkflow: new Exception handling

(this discussion was moved to the os-workflow list)

Come on folks, Josh Bloch's book isn't a bible, and all this quoting of
his tome is getting a bit out of hand.

Anyway, I disagree somewhat with what you pasted, as does the core JDK. A
SQLException is not recoverable, for example. I'd say a better rule of
thumb is 'provide a checked exception if you think the caller might care
about what actually went wrong'. Alternatively, if you define 'recovery'
as being 'handle in some way or another beyond blowing up' then I agree
with the quote!

Sullivan, Sean C - MWT said:
>
> Speaking of exception handling...
>
> Josh Bloch's book "Effective Java" provides a couple of
> good rules of thumb for exception handling.
>
> {{
>
> Item 40:  Use checked exceptions for recoverable conditions
>           and run-time exceptions for programming errors
>
>
>   	"To summarize, use checked exceptions for recoverable
> 	 conditions [...] If you believe a condition is likely
>        to allow for recovery, use a checked exception; if not,
>        use a run-time exception."
>
>
> Item 41:  Avoid unnecessary use of checked exceptions
>
> Item 43: Throw exceptions appropriate to the abstraction
>
> }}
>
> I highly recommend "Effective Java".
>
> -Sean
>
>
>
>> -----Original Message-----
>> From: Nick Dellamaggiore
>>
>> 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
>> _______________________________________________
>> Opensymphony-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/opensymphony-developers
>
>
> -------------------------------------------------------
> 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
> _______________________________________________
> Opensymphony-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-developers






-------------------------------------------------------
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