[Biojava-l] Lazy instantiation and the Sequence interface
David Huen
David Huen <smh1008@cus.cam.ac.uk>
Sun, 24 Jun 2001 13:56:12 +0100 (BST)
On Sun, 24 Jun 2001, Thomas Down wrote:
Dear Thomas,
> On Sat, Jun 23, 2001 at 08:57:30PM +0100, David Huen wrote:
>
> What's currently happening in biojava-ensembl is that runtime
> errors are causing BioErrors to be thrown, since that was what
> was available. I think this is wrong, since it means you actually
> get code which catches Errors (which is missing the point of
> Errors). One other possibility would be:
I've tried this one for the time being on the test code, it being the path
of least resistance but I agree it's a heck of an ugly hack. It'll be
easy for me to change over to whichever route is finally decided on from
here though.
> 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?
>
>
> 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).
Anyway, I'd go with whichever of the many routes gets decided on.
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.
Regards,
David H.
P.S. Seen the Wiki lately? It's got a lot more docs!
P.P.S. I've made a start on RagbagDataSource for Dazzle.