[Biojava-l] ChangeVetoExceptions

[Matthew Pocock]

Hi Mark,

I tend to be in the 'All exceptions should be checked' camp, but I do 
bemone the stupidness of the java compiler when it comes to working out 
when exceptions can never be thrown. It sort of comes back to 
restrictions not being types (e.g. I can't specify a type 0..100, or 
Sequence not NULL). If this was available to the compiler, it could 
potentialy root out lots of exceptions. The beauty of hind-sight.

The other thing is, occasionaly 'impossible' exceptions do get thrown. 
The requirement to handle these (if only to wrap them in an error or 
run-time exception) forces these bugs out into the open at a much 
earlier stage in development. I think what we are seeing is the 
different reqirements of robust library development and short-lifetime 
script hacking.

Is the general feeling that typed exceptions are good or bad?

Matthew

Mark Schreiber wrote:

> 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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> _______________________________________________
> Biojava-l mailing list  -  Biojava-l@biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
> 
> 
>