[Biojava-l] ChangeVetoExceptions

Thomas Down td2@sanger.ac.uk
Mon, 16 Jul 2001 14:41:27 +0100


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.