This is the mail archive of the
frysk@sourceware.org
mailing list for the frysk project.
Re: Frysk exceptions
* 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.