[Biojava-l] Lazy instantiation and the Sequence interface

[Thomas Down]

On Sun, Jun 24, 2001 at 01:56:12PM +0100, David Huen wrote:
> 
> > 4) Define BioRuntimeException.  Document that all the problematic
> > methods on Sequence (and friends) can throw this (explicitly list
> > it in the Javadoc).  The advantage of this is that it won't actually
> > break any existing code.  The downside is that it will make well-written
> > future code even more complex in exception handling (you'll easily
> > get blocks which can throw both BioException and BioRuntimeException.
> > This is when you wish for "public class BioRuntimeException extends
> > BioException, RuntimeException"....)
> 
> I don't understand Java exceptions well enough here.  If I use a
> Biojava.jar with this implemented on code compiled with an earlier
> non-BioRuntimeException version, it will work without recompiling
> the apps?  That might be a route then.  Will it also mean that if they
> recompile against the new library, the compilation will break then?

Yes, that's the idea.  For reference, there are 3 types of
exception (well, Throwable) in Java:

  - `Normal' exceptions: Exception and subclasses.  These are
    always checked at compile time -- you have to either catch
    them or explicityly include them in your `throws' list.

  - Runtime exceptions: These aren't checked at compile time.
    They are subclasses of Exception, so catch (Exception) will
    get them.

  - Errors.  Also unchecked.  These /aren't/ subclasses of
    Exception, so catch (Exception) doesn't get them.  It
    is technically possible to catch them, but the idea is
    that they only get thrown when Something Really Bad has
    happened, so you shouldn't catch them.

RuntimeExceptions get used in the collections framework, for
instance.  The idea is that if you're expecting them you're
free to catch and handle them, but you're also allowed to ignore
them (and just have your program bomb out if one gets thrown
unexpectedly).

> > Anyway, since you're asking for opinions, my preferences are 3
> > or 4 (in that order).  I'd really like to fix the Sequence interface
> > (and a few others in that order), but it's going to make a significant
> > amount of work for people.  So some serious discussion is in order
> > here -- this is an issue which is just going to keep coming back
> > until somebody fixes it...
> > 
> > Thinking back to the roadmap I proposed a few days ago:
> > 
> >   BioJava 1.2 (coming soon):
> > 
> >     Add BioRuntimeException.  Encourage new code to catch this.
> >     Applications which don't may just bomb out.  However, programs
> >     which /just/ use in-memory objects (and are therefore okay at
> >     the moment) in practice won't be hit by this, so it's not actually
> >     an incompatible change.  Proper support for the runtime exetpions
> >     can be phased in for new code.
> > 
> >   BioJava 2.0 (end of this year, early next)
> > 
> >     We're already targetting things like universal identifiers
> >     and universal queryability to this release, so interfaces WILL
> >     change if these get landed.  This means it's potentially a lower-
> >     impact point to roll some of the core interfaces ( like Sequence)
> >     over to throwing checked exceptions.  We'll have had a chance to
> >     see exactly how well the BioRuntimeException model is working
> >     out, and make an informed decision on this.
> > 
> > I think it would be a shame to see Ragbag postponed because of
> > this, especially since this issue effects other code (including
> > code which is already in the project).
> > 
> Personally I'd prefer either:-
> 1) fix the interfaces now and followup all the sequelae for 1.2.
>
> OR
> 2) use BioError temporarily and fix the interfaces for 2.0.  Then do it
> with the correct Exception model whichever that might be.  This route gets
> Ragbag and 1.2 in within your original timeframe.
> 
> I suspect introducing BioRuntimeException may cause some code to commit to
> a new complex dependency that needs fixing in 2.0.  Complex tests are more
> difficult to back out later if it doesn't work out (for me anyway, I can't 
> keep enough in my head at one time to write complex code).

The poit of BioRuntimeException is that you don't /have/ to
catch it.  In one-shot programs you almost certainly wouldn't.

Graphical applications, servers, and the like would probably want
to, though.  And yes, you're right, there will be extra complexity
here :(.  That said, I'd rather go the BioRuntimeException route
than have application writers learn about how we're using Errors
and start catching those (which seems to go against the whole point
of Errors).

> Just incidentally, do we have a listing of all code that currently uses
> this library?  Are there apps out there that are not in CVS?  What's in
> CVS we can fix for interface changes readily but we can't fix what we
> don't know about.

It's very hard to know.  I suspect a lot of BioJava code is small
internal programs, either for one-off tasks, or in analysis pipelines
(etc.).  Certainly I've written a lot of one-shot BioJava appls
(both in Java, and also in Tcl-Java).

> [Wiki]

Looks good!  It might be worth having a prominant link
from the website front page (as opposed to the Wiki root)
to the FAQ sections.

> [Ragbag and Dazzle]

Nice ideas.  Just a quick heads-up...

I'm doing a big refactor of Dazzle, to get the DAS/0.996
compliance right and tidy up lots of cruft.  One consequence
of this is that the DASDataSource interface is changing
quite significantly (the old interface grew up quite organically,
which explains why it's so strange...).  I'm about half way 
though at the moment -- I'd like to get it done for tommorow,
but failing that it will be sometime next week.  The basic
concept is still the same, just API changes you should be
aware of.

   Thomas.