[Biojava-l] ChangeVetoExceptions

[Mark Schreiber]

Hi -

I generally agree that checked exceptions are safer and for throw away
programs I tend to catch exceptions and throw errors but I have recently
read a number of articles (mostly in java world) that have called into
question the "design flaw" of enforced exception handling.

According to these the original plan was to make Java safer however some
exceptions such as NullPointerExceptions couldn't be enforced as you would
have to catch them everywhere so the plan wasn't really implemented as it
was designed. The reason being that a compiler was not smart enough to
figure out if an exception was likely (or even possible). A truely smart
compiler could tell that my internal SequenceDB had never been locked from
adding new features and therefore could never throw an exception.

Some of the developers who wrote the articles had moved to using more
custom exceptions derived from runtime exceptions and catching when and if
needed. The upshot was ~30% reduction in code along with accompianing
decreases in maintenance and bugs. These developers included those who
developed large distributed systems. The secret was a little knowledge of
when an error could occur and what to do with it. Most of the caught
exceptions in java where not being caught at all, just left to die with a
stack trace. The other secret was excellent API documentation specifying
@throws statement that contained information about what might cause the
unenforced exception and what could be done about it. The developer could
then decide what needs to be caught and what doesn't.

This seems more elegant but also requires more experience from the
programmer and more detailed documentation. I think that Biojava already
contains enough advanced stuff to require a good familiarity with biojava
so developers should be able to cope with some unenforced exceptions.
Documentation could be the downfall of what seems to be an elegant
solution as it would require some class methods (possibly many) to be
redocumented :(

Mark

On Mon, 16 Jul 2001, Thomas Down wrote:

> On Mon, Jul 16, 2001 at 09:52:38AM +1200, Schreiber, Mark wrote:
> > 
> > Hi -
> > 
> > I was wondering if it might be better if ChangeVetoException could be
> > subclassed from an unchecked exception.
> > 
> > I know that unchecked exceptions are a contentious issue in java but in many
> > cases when writing a simple program I want to add a feature to an internal
> > feature holder or a sequence to an internal SequenceDB where there is no
> > possibility of an exception been thrown. By making it an unchecked exception
> > a lot of cruft could be removed from simple programs. By clearly labelling
> > the methods that through a ChangeVetoException developers of more
> > interoperable applications could be made aware of the possible need to catch
> > this exception. In the simple case of a temporary SeqDB or similar it would
> > be best to let the program die as a ChangeVetoException here would indicate
> > something seriously wrong with the program or the biojava class.
> 
> Generally, I find programs my Java programs fall into
> two categories: serious things, where I actually care about
> exceptions, and `quick hacks' which are throwaway solutions
> to a specific problem, and tend to have `throws Exception' on
> every method (including main...).
> 
> The general pattern we've adopted so far has been:
> 
>   FeatureHolder myFeatures = new SimpleFeatureHolder();
>   try {
>       myFeatures.addFeature(new FooFeature(blah));
>   } catch (ChangeVetoException cve) {
>       throw new BioError("Assertion failed: couldn't add features");
>   }
> 
> I know the try block /is/ a bit of a bother when you know that
> the operation is going to succeed.  But the `guarenteed success'
> case isn't /that/ common, and using checked exceptions is a good
> way to encourage robust code.
> 
> 
> What I /would/ like to see is a generic BioJava RuntimeException
> (BioRuntimeException?), so that if execution fails in a method
> which can't throw any checked exceeptions (quite common, now
> that we're writing all sorts of lazy-loading implementations of
> BioJava objects) you can throw something a little less destructive
> than a BioError.
> 
> This was discussed a little bit a few weeks ago, but dieed
> down before many people had declared an opinion one way or
> another.  What do you think?
> 
>       Thomas.
> _______________________________________________
> Biojava-l mailing list  -  Biojava-l@biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
> 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mark Schreiber			Ph: 64 3 4797875
Rm 218				email mark_s@sanger.otago.ac.nz
Department of Biochemistry	email m.schreiber@clear.net.nz
University of Otago		
PO Box 56
Dunedin
New Zealand
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~