Re: Frysk exceptions

[Sami Wagiaalla <swagiaal@redhat.com>]

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