Bioperl: RFI response, appendix (fwd)

[Steve A. Chervitz]

Georg wrote:

> Steve wrote,
> >>>>>>>>
> 8. Highly fault-tolerant. 
> ...       It is preferrable to throw fatal exceptions when data
>           inconsistencies or other serious problems are encountered,
>           rather than generating warnings that cannot be
>           programmatically handled, or relying on a polling mechanism,
>           or relying on the software's inherent ability to accomodate
>           the discrepency.
> <<<<<<<<
> As before, I'd suggest to prefer warnings to fatal exceptions.
> Some of my runs take days (90 sequences, each 3000 nucleotides each,
> are subjected to thousands of alignment calculations), and I don't wanna 
> lose the end result b/c of some stupid exception. Fatal exceptions are OK
> for small scripts, but not for larger applications, as long as there
> is a reasonable way to handle them: garbage in, garbage out is OK for
> me as long as warnings are issued.


The most reasonable way to handle exceptions is simply to wrap any block 
of code that can generate them into an eval{} block:

foreach $seq (@sequences) {
    eval{ process_seq($seq); };
    if($@) { warn "Didn't process sequence $seq: $@\n"; 
             push @errs, $@;
       	    }
}

At the end of the day, you always can dump @errs to a file for further 
inspection. This way, one bad sequence won't bring down the script and 
you have an convenient mechanism to identify the trouble-makers.

You may ask, "How do I know where exceptions might be generated?" 
Answer: by reading the documentation and/or source provided with the 
method(s) you are using, which should make this clear. Even without this 
knowledge, you can always eval{} the critical sections of your code just to 
be safe. 


> >>>>>>>>
> 10. Ability to use individual components stand-alone or within a framework. 
> ...       This issue has not been adequately addressed with the Bioperl
>           framework. At present, different versions (stand-alone or
>           integrated) of selected components are generated by hand as
>           needed. This is creates the problem of synchronizing the
>           different versions as updates are released. This is a
>           difficult problem and solutions are being considered.
> <<<<<<<<
> Which solution(s) do you envision ?

One idea is to automate the updating and framework integration 
mechanics within a Makefile script which would know how to 
customize a given module for operation within the framework. This would 
still leave you with two (or more) versions of the module, however. 

Another idea is to use an adapter or wrapper module that mediates the 
interactions between the module and the framework. This would allow a 
single module to be used in either context. Exactly how this would work 
is not clear since it really depends on the design of the framework. It  
certainly would add complexity since you would have twice as many interfaces 
to deal with (module-adapter + adapter-framework versus just 
module-framework). You may need custom adapters for different modules 
instead of one universal adapter for connecting all modules into a given 
framework.

The third option is to just have one version of the module, dedicated to 
stand-alone operation or operation within some framework, and avoid 
the issue altogether. Still, it would be nice to use the module within 
different contexts and to uncouple the development of a module from the 
development of the framework. Thinking up ways to facilitate this process 
is at an early stage.

There are probably other possiblilities. Thanks for the comments and keep 
them coming!

SteveC


=========== Bioperl Project Mailing List Message Footer =======
Project URL: http://www.techfak.uni-bielefeld.de/bcd/Perl/Bio/
For info about how to (un)subscribe, where messages are archived, etc:
http://www.techfak.uni-bielefeld.de/bcd/Perl/Bio/vsns-bcd-perl.html
====================================================================