[Biojava-dev] an outsider's take on Biojava 3

[Richard Holland]

RuntimeException is good for things that can't be recovered from. If the
user has provided bad coordinates or invalid sequence, that's a
recoverable error (because there's a chance that they came from user
input via a user interface, which can be corrected and retried). Even
file parsing exceptions should be recoverable - the user can move on to
the next record without borking the entire file (we already see broken
records quite a lot in Genbank downloads).

But, for things like being unable to call out to Blast, or being unable
to convert DNA to Protein because of a misconfiguration internally
somewhere, I agree that RuntimeExceptions are probably best. These are
unrecoverable and indicate that changes need to be made to the
programming code or BioJava itself.

So in my mind then RuntimeExceptions are good for highlighting
programming errors, but not good for errors relating to invalid input
data.


On Fri, 2009-05-22 at 11:01 +0800, Mark Schreiber wrote:
> Sorry, sent before I said what the new principles were.
> 
> 1. Extensive use of the Logging API
> 2. (At the risk of having a fatwa declared against me) Most biojava
> exceptions should derive from RuntimeException and be unchecked
> 
> See the wiki page for more details.
> 
> - Mark
> 
> On Fri, May 22, 2009 at 10:59 AM, Mark Schreiber
> <markjschreiber at gmail.com> wrote:
> > Thanks for the comments. The OSGi system sounds interesting. I think
> > we should consider it.
> >
> > I have also added two more recommendations for the Design Principles:
> >
> >
> > On Fri, May 22, 2009 at 7:47 AM, Mike Smoot <msmoot at ucsd.edu> wrote:
> >> Hi Everyone,
> >>
> >> I thought I'd respond to Andreas' request for participation in the BioJava 3
> >> design discussions that he made last week on the normal BioJava list.  I'm
> >> the lead developer on the Cytoscape project (http://cytoscape.org), so I
> >> thought I'd provide some perspective on what a project using BioJava might
> >> look for in BioJava 3.
> >>
> >> Basically, I'd just like to voice my strong support for the "Basic
> >> Principles" listed here: http://biojava.org/wiki/BioJava3_Design.  Finer
> >> granularity of jars, acyclic dependencies, and the separation of API and
> >> implementation are precisely the things we're doing in Cytoscape 3.  The
> >> first two points will go a long way towards making it easier to use specific
> >> parts of the library without needing everything at once.  The second point
> >> will allow alternative implementations of certain interfaces, which is one
> >> approach to dealing with issues like parallel vs. non-parallel versions of
> >> algorithms.  Maven also sounds great.
> >>
> >> If I could add one bullet to the list, it would be to add OSGi metadata to
> >> the jars to allow easy integration with OSGi-based projects (such as
> >> Cytoscape 3 and (as I'm told) the next version of Taverna). There are maven
> >> plugins to make this dead simple and it wouldn't impact anyone not using
> >> OSGi.
> >>
> >> Please take that with a large grain of salt, I just thought you might
> >> appreciate an outsider's perspective!
> >>
> >> thanks,
> >> Mike
> >>
> >> --
> >> ____________________________________________________________
> >> Michael Smoot, Ph.D.               Bioengineering Department
> >> tel: 858-822-4756         University of California San Diego
> >> _______________________________________________
> >> biojava-dev mailing list
> >> biojava-dev at lists.open-bio.org
> >> http://lists.open-bio.org/mailman/listinfo/biojava-dev
> >>
> >
> 
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biojava-dev
-- 
Richard Holland, BSc MBCS
Finance Director, Eagle Genomics Ltd
T: +44 (0)1223 654481 ext 3 | E: holland at eaglegenomics.com
http://www.eaglegenomics.com/