Frysk exceptions

Frysk exceptions

[Sami Wagiaalla]

I have been meaning to write this for a while to clarify to my self the 
frysk strategy with respect to Exceptions and handling.

These are my practices; please tell me if you agree or disagree:

  * All frysk exceptions are (should ?) be unchecked exceptions ie 
extend RunTimeException.
  * Exceptions should never ever be ignored.
  * Exceptions can be ignored (handled) if they are specific enough (eg 
operation XYZFailedException)
  * Except for certain cases catch statements should be as specific as 
possible.
     So no catch(Exception e) statements, but 
catch(SymboleNotFoundException e).
  * Exceptions are better than returning null.

All other exceptions -which are not caught-, should be printed out in 
the most obvious way possible. This tells the use that there is a bug in 
frysk and that they should report it. The alternative (if it was logged, 
or cleaned up) is that the user assumes it is a non fatal error and 
continues to use frysk only to find it in a bad state much later. 
Resulting a difficult problem to debug.

Re: Frysk exceptions

[Phil Muldoon]

Sami Wagiaalla wrote:
> I have been meaning to write this for a while to clarify to my self 
> the frysk strategy with respect to Exceptions and handling.
>
> These are my practices; please tell me if you agree or disagree:
>
>  * All frysk exceptions are (should ?) be unchecked exceptions ie 
> extend RunTimeException.

Right but they aren't. There are checked exceptions throughout the code 
base from history. They will be fixed over time,  but just a note that 
they exist right now.

>  * Exceptions should never ever be ignored.

One of the downsides of a unchecked exception is that one has to have a 
good knowledge of the code-base to catch an unchecked exception. The 
very nature of unchecked exceptions means they do not have to be 
explicitly caught. That means all the usual ecj compiler checks will not 
catch any leaks. Not sure what to do here, except that the top level 
commands in fhpd/ui need to be very careful of intercepting said 
unchecked exceptions. You can fix this by catching the big unchecked 
exception superclass .....................

>     So no catch(Exception e) statements, but 
> catch(SymboleNotFoundException e).

This drills into the fact that one can expect to catch unchecked 
exception foo, but rather unchecked exception bar happens instead which 
is uncaught. Caution needs to be exercised that we are not falling into 
the checked exception trap, even though the exception is unchecked. If 
you start expecting callers to catch various different forms of 
unchecked exceptions and creating a policy around that, then I think we 
need a bit of a think on strategy. It creates a huge burden on the 
caller of the api to have underlying knowledge of the code beyond that 
api call. I constantly fall into the trap of writing code for myself, 
but not to a wider unsuspecting audience. This is usually re-factored 
out, but 5 years from now will user Joe know he has to catch several 
different flavors of undeclared, unchecked exceptions?

>  * Exceptions are better than returning null.
>

I cringe at NPEs in particular as they inform the user the programmer 
was not diligent in checking the return of each function for sanity. 
It's easy to do in chaining commands (ie foo().geBar().getFooBar()) but 
I think from the user point of view it's pretty compelling evidence of 
insufficient sanity checking.

Regards

Phil

Re: Frysk exceptions

[Sami Wagiaalla]

>>  * Exceptions should never ever be ignored.
>
> One of the downsides of a unchecked exception is that one has to have 
> a good knowledge of the code-base to catch an unchecked exception. The 
> very nature of unchecked exceptions means they do not have to be 
> explicitly caught. That means all the usual ecj compiler checks will 
> not catch any leaks. Not sure what to do here, except that the top 
> level commands in fhpd/ui need to be very careful of intercepting said 
> unchecked exceptions.
I meant that exceptions should not be swallowed. As in catch(Exception 
e){//mum}

> You can fix this by catching the big unchecked exception superclass 
> .....................
>
>>     So no catch(Exception e) statements, but 
>> catch(SymboleNotFoundException e).
>
> This drills into the fact that one can expect to catch unchecked 
> exception foo, but rather unchecked exception bar happens instead 
> which is uncaught. Caution needs to be exercised that we are not 
> falling into the checked exception trap, even though the exception is 
> unchecked. If you start expecting callers to catch various different 
> forms of unchecked exceptions and creating a policy around that, then 
> I think we need a bit of a think on strategy. It creates a huge burden 
> on the caller of the api to have underlying knowledge of the code 
> beyond that api call. I constantly fall into the trap of writing code 
> for myself, but not to a wider unsuspecting audience. This is usually 
> re-factored out, but 5 years from now will user Joe know he has to 
> catch several different flavors of undeclared, unchecked exceptions?
This is a good  point. I hadent thought about it before. But, if Joe 
runs his code and gets a SymboleNotFound exception they can relate that 
to the function call they made and handle the exception.