[Bioperl-l] Grrrr. Another subtle overloading bug ...

[Chervitz, Steve]

Folks,

Apologies for causing trouble. So much for my attempt at transparency!
I've just checked in a fix to Bio::Root::Root::throw() that will ensure
backward compatibility for eval{}-based exception handling.

When I made changes in Root::throw(), I also added a variety of examples in
examples/exceptions that demonstrated the new functionality and tested for
backward compatibility (specifically, test2.pl and test4.pl in that dir).
They were all working, or so I thought.

I agree with Hilmar's comments re: exceptions. My aim was to be completely
transparent with the current exception throwing/handling methodology, yet to
enable users to get fancier if they want to, and have a standard way to get
fancy, instead of creating multiple, incompatible Bioperl extensions. I
realize this goal can be difficult to achieve. If the current system doesn't
cut it, I'm OK with reverting back to the old ways.

It would be nice if Error::throw() could be used within an eval{} block so
that the traditional if($@) syntax would work with Error objects. This will
take some digging into Error.pm to see what's going on here.

In the meantime, eval{}-based exception handling should be working again
after you cvs update. My examples/exceptions/test2.pl and test4.pl should
suffice as  backward compatibility tests. Feel free to add to them as you
see fit. Sorry again for my lapse in testing.

Steve

> -----Original Message-----
> From: Ewan Birney [mailto:birney@ebi.ac.uk]
> Sent: Sunday, January 06, 2002 10:39 AM
> To: bioperl-l@bioperl.org
> Subject: [Bioperl-l] Grrrr. Another subtle overloading bug ...
> 
> 
> 
> 
> SteveC - you are going to get awards for introducing the most 
> bizarre bugs
> across bioperl namespaces if we are not careful....
> 
> 
> The new Exception class SteveC checked in (at my behest to get things
> checked in early) now throws objects not scalars...
> 
> 
> These objects have a stringify method which evaluates to the expected
> string when printed - quite right
> 
> 
> ... but there is a *VERY* nasty side-effect ....
> 
> 
> which is that scenarios like
> 
> 
>   eval {
> 	# do complex stuff
> 	# which might throw an exception
>   };
> 
>   if( $@ ) { # you would expect this to evaluate to "true" on 
> exception
>     # do something else, like return failure gracefully
>   } else {
>     # do something sanely
>   }
> 
> 
> This construct WONT work. <sigh>
> 
> The reason is that 
> 
>   if( $@ ) triggers the "stringify" method, which gives back 
> a nice piece
> of text and then gets evaluated as a number (I think...), 
> which goes to 0
> which evaluates as .... FALSE.
> 
> 
>   ...Grrrrr...
> 
> 
> I suspect world wide we have lots of
> 
>   if( $@ ) {
> 
>   }
> 
> 
> (certainly there is alot in Ensembl...)
> 
> 
> Now ... I have commited some tests to fix this but then I 
> realised that
> this is probably a bad idea and we need to fix things so that
> 
> 
>   if( $@ ) {
>    #
>   }
> 
> Evaluates to TRUE. SteveC - do you know how to do this. I have spent a
> fruitless half an hour in perl.com trying to find the overloading
> documentation.
> 
> 
> 
> This is a nasty bug and something we have to get right. It 
> also emphasises
> how important it is to test the 0.9 series before we call it 
> 1.0 otherwise
> we will just trigger alot of bugs world-wide...
> 
> 
> 
> ewan
> 
> 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@bioperl.org
> http://bioperl.org/mailman/listinfo/bioperl-l
>