[Bioperl-l] Exceptions and Interfaces

[Chervitz, Steve]

Ewan Birney [mailto:birney@ebi.ac.uk] wrote:
> 
> My take on this is that our current throw() mechanism is 
> really "Error.pm
> written for ourselves". Error.pm is becoming the standard and 
> I think at
> some point we have to bite the bullet and use this rather 
> than strings. 
> 
> 
> As for hilmar's point --- I agree that we shouldn't require 
> some model to
> be bioperl compliant. 

Agreed.

> Over all I think the aim would be to move towards allowing 
> Error.pm being
> "thrown" as well as strings, with RootI probably making a
> Bio::Root::StringException for current $self->throw("this is a
> message") and allow $self->throw($exception) (assumming this 
> is the way
> Error.pm works). We should probably have another Bio::Root::Exception
> class which handles the stack trace deduction etc...

Allowing RootI::throw() to take an Error.pm-based exception object is a
possibility. However, there's a complication due to the fact calling
Error::throw() within an eval block doesn't lead to anything getting added
to $@. So if someone is using an outer eval{} instead of try{} to catch
exceptions, the exception will go unnoticed if RootI uses Error::throw().
One way around this is that RootI::throw() could examine the call stack and
determine if try{} is being used.

If an outer eval{} block isn't being used, then Error::throw() behaves just
like die(), so no problem there.

Regarding stack traces, Error.pm does this, but the ouput isn't as nice as
produced by RootI. I wrote a pretty_format() method in Bio::Exception that
creates output similar to RootI, but it doesn't finagle with the line
numbers. (BTW, my Bio::Exception should probably be within Bio::Root.)

Steve

> 
> I agree with Hilmar that this is not a must-have for 
> bioperl... but if you
> want to roll it in then I'd be happy to have it ;)
> 
> 
> 
> -----------------------------------------------------------------
> Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
> <birney@ebi.ac.uk>. 
> -----------------------------------------------------------------
>