[Bioperl-l] Exceptions and Interfaces

[Chervitz, Steve]

Thanks for the comments, Hilmar. I'm forwarding my responses to the list to
keep everyone in the loop.

Steve

Hilmar Lapp [mailto:hilmarl@yahoo.com] wrote:
> 
> "Steve A. Chervitz" wrote:
> > 
> > I put together a little demo of a neat way to throw
> > and handle exceptions within Perl that I'd like to propose
> > for adoption as a BioPerl standard. This also includes a module
> > (Bio::Root::Interface) that I'm proposing for use as a base class
> > for all BioPerl interface modules -- something that we've talked
> > on and off about having.
> 
> 1) I have to admit that I don't see why all interfaces should be
> required to inherit off anything. Interfaces in fact are there to
> specify the bare API implementors have to follow, and should be as
> basic as possible in order to be useful for implementors *outside*
> of Bioperl, too. E.g. Bio::LiveSeq reimplements all the
> interfaces, and Heikki didn't want to depend on RootI (I'm not
> sure those modules are still independent), which worked out fine.
> Similarly for Ensembl. External implementors will not want to be
> burdened with the maze of bioperl dependencies when they just want
> to be interoperable with Bioperl.
> 
> In other words, interfaces shall be self-contained (there are
> interfaces specializing on others, though, but this is different
> from what I mean).

The idea behind Bio::Root::Interface is to make it easy for other interfaces
to throw "not implemented" exceptions within their method definitions in a
way that is sensitive the presence of Error.pm. Bio::Root::Interface can
make use of Error.pm if it is installed. 

There would be no requirement that all interfaces must extend this base
interface, but if they wanted to conditionally make use of Error.pm,
Bio::Root::Interface would save them from re-inventing the wheel.

> 2) From a software engineering point of view I agree with you that
> a robust and flexible exception handling model is quite
> beneficial. Nevertheless, I think we should be careful not to lose
> track of the kind of goals we want to achieve and the kind of
> users we're targeting, where users include (potential) developers.
> Frankly, I haven't heard anyone complaining about the exception
> handling model in Bioperl. I even doubt that a big fraction of the
> bioperl user community knows where or how to sensibly put
> try/catch blocks in the code. Similarly, I doubt that there are
> even a dozen people on the list caring about CORBA, let alone
> actively using it. (I'd enjoy to be disproven though.)

Yes, the exception handling in my proposal is more interesting to developer
types than end user types. So I feel that the use of Error.pm should be
transparent to your average user. I've gone to the trouble of making sure
this is so in Bio::Root::Interface. 

> My concern here is that the system shouldn't become more complex
> than it is absolutely necessary to achieve the desired flexibility
> and stability, in order to keep the bars low for other people
> who've got itches to solve. The KISS principle, you know. We've
> got some recent feedback pointing in this direction, and while I
> agree that flexibility and power do come at a price, and it is
> worth to pay that price, I also think some care should be taken
> that the price is not higher than it really has to be.
> 
> Personally, I think Perl has got its strengths, and OO-languages
> got theirs, too. To a considerable extent, these are disjoint. I
> don't think it makes that much sense putting big efforts into
> covering up Perl's quite obvious weaknesses. I'd rather put
> efforts into exploiting the strengths. That said, we're already
> finding ourselves limited in flexibility because of Perl's weak
> (in fact, non-existant) OO model ... 
> 
> Returning to your proposal, I don't think imposing the constraints
> that would ensue your proposal is a good idea. So the question is
> how your problem could be solved otherwise. In my view, this
> appears to be calling for a pluggable exception handling model.
> There would be a very simple default one, but the system allows
> for plugging in one that is as full-featured as your proposal.

I agree that pluggability is key here. As Perl's built-in exception handling
capabilities evolve, we'll want to be able to take advantage of them instead
of relying on external modules.

Steve 

> Ewan, Jason, don't hesitate to object or set me straight if you
> disagree with me.
> 
> 	Hilmar
> -- 
> -----------------------------------------------------------------
> Hilmar Lapp                              email: hilmarl@yahoo.com
> GNF, San Diego, Ca. 92122                phone: +1 858 812 1757
> -----------------------------------------------------------------
>