[ensembl-dev] error API

Kieron Taylor ktaylor at ebi.ac.uk
Wed Jun 10 17:04:00 BST 2015


Hi Nathalie,

I’ve made some modifications to the API to handle your issue. They will be generally available as of release 81 some time in July. Until then, the code can be found on Github as part of the master branch.

Regards,

Kieron


Kieron Taylor PhD.
Ensembl Core senior software developer

EMBL, European Bioinformatics Institute





> On 9 Jun 2015, at 17:01, Nathalie Conte <nconte at ebi.ac.uk> wrote:
> 
> Thanks all for your advices and the fix, script is now running for chr17. Please let me know when the method is changed
> Nathalie
> On 9 Jun 2015, at 15:00, "Healy, Matthew" <Matthew.Healy at bms.com> wrote:
> 
>> 
>> Note that Kieron's code example wraps the call in an eval block, then checks a value that should have been set inside the eval block, which is the right way to do that.  A more general pattern for an eval block is:
>> 
>> eval {
>>      #code for which you want to trap errors
>>      # ... do various things in here
>> 
>> 
>>      # then make sure it returns 1
>>      1;
>>    } else { # do your error handling stuff };
>> 
>> Which is basically what Kieron did, except that he used the value of $nearest_genes because if the call to $vf->get_nearest_Gene succeeds then it will resolve to truth (http://perldoc.perl.org/perlsyn.html#Truth-and-Falsehood) and if it fails then it will be undef which does not resolve to truth.  In the general case, especially if you do multiple things inside the eval block, it's wise to have the very last code in your eval block return a true value and branch on that.
>> 
>> Many examples on the web and in textbooks instead check the $@ variable which has the most recent error state:
>> 
>> eval {
>>      #code for which you want to trap errors
>>      # ...
>>    };
>> If ( $@ ) { # error handling }
>> # this is NOT recommended, branch on a value set within the eval block instead
>> # of branching on $@
>> 
>> This will work MOST of the time, but can be fragile because your eval block is not the only thing that could change $@
>> 
>> As Kieron notes, Try::Tiny will do the right thing without you having to know these subtleties -- at the cost of a little overhead.
>> 
>> -----Original Message-----
>> From: dev-bounces at ensembl.org [mailto:dev-bounces at ensembl.org] On Behalf Of Kieron Taylor
>> Sent: 09 June, 2015 9:35 AM
>> To: Ensembl developers list
>> Subject: Re: [ensembl-dev] error API
>> 
>> Our Variation team have been doing a lot of work on remapping variants recently. I refer to release 79:
>> 
>> http://mar2015.archive.ensembl.org/Homo_sapiens/Variation/Explore?r=17:7221675-7222675;v=rs398123092;vdb=variation;vf=68694995
>> 
>> If you want your code to survive aberrant data (until I've patched it at least), do this:
>> 
>> 
>> delete:   my $nearest_genes = $vf->get_nearest_Gene;
>> replace with:
>> my $nearest_genes;
>> eval { $nearest_genes = $vf->get_nearest_Gene };
>> 
>> Then consider writing the IDs that don't resolve to another file, so you can know how many failures there were, e.g.
>> 
>> if ($nearest_genes) {
>> ... successful code
>> } else {
>> print STDERR $vf->variation_name . "\n"; }
>> 
>> Regards,
>> 
>> Kieron
>> 
>> n.b. Try::Tiny is better than eval{} in general, but harder to show you how to change your code.
>> 
>> ---
>> 
>> Kieron Taylor PhD.
>> Ensembl Core senior software developer
>> 
>> EMBL, European Bioinformatics Institute
>> 
>> 
>> 
>> 
>> 
>>> On 9 Jun 2015, at 14:22, Nathalie Conte <nconte at ebi.ac.uk> wrote:
>>> 
>>> Hi Kieron,
>>> thanks for your fast answer.
>>> this rsID resolves on chromosome 17 on the GUI ?? rs398123092
>>> http://www.ensembl.org/Homo_sapiens/Variation/Explore?r=17:7221675-722
>>> 2675;v=rs398123092;vdb=variation;vf=60351773
>>> 
>>> Could you please help me with the fix you suggest, ie syntax and where to place it in the script?
>>> cheers,
>>> Nathalie
>>> 
>>> 
>>> On 9 Jun 2015, at 13:54, Kieron Taylor <ktaylor at ebi.ac.uk> wrote:
>>> 
>>>> Hi Nathalie,
>>>> 
>>>> Thank you for the report, I think you've uncovered a combination of issues. The rsID you mention resolves to chromosome 13 on release 79 (and not 17? Perhaps you looked it up on the website to check), and can be seen to be in a massive region of N's. The code limits its search radius, doesn't find anything and rather too optimistically assumes it will succeed. I will fix it so that get_nearest_Gene stops dying if there is nothing to be found.
>>>> 
>>>> In the mean time, you could trap the error with Try::Tiny or an eval{} block, so that your code survives this variant. With that much empty space around it, I don't think the nearest gene has useful meaning.
>>>> 
>>>> 
>>>> Regards,
>>>> 
>>>> Kieron
>>>> 
>>>> 
>>>> Kieron Taylor PhD.
>>>> Ensembl Core senior software developer
>>>> 
>>>> EMBL, European Bioinformatics Institute
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On 9 Jun 2015, at 12:17, Nathalie Conte <nconte at ebi.ac.uk> wrote:
>>>>> 
>>>>> 
>>>>> Dear Dev team,
>>>>> 
>>>>> I am running a script to get various annotation from Variation IDs I fetch from ensembl.
>>>>> I am running this for every chromosome and it works for all but  chromosome 17 where it stops  throwing this error message where I am trying to use get_nearest_Gene function from the variation feature.
>>>>> Can't use an undefined value as an ARRAY reference at home/Bio/EnsEMBL/Feature.pm line 1452.
>>>>> 
>>>>> 
>>>>> while (<INFILE>){ #file where variation ID are captured my @data
>>>>> =split /\t/;
>>>>> 
>>>>> my $variation_human = $data[2]; #rsID
>>>>> next if (!$variation_human) ;
>>>>> my $human_query_variation =
>>>>> $v_adaptor->fetch_by_name($variation_human);
>>>>> 
>>>>> if (!$human_query_variation){ next;
>>>>> } else {
>>>>> my $mvfs  =
>>>>> $vf_adaptor->fetch_all_by_Variation($human_query_variation);
>>>>> 
>>>>> foreach my $vf (@{$mvfs}){
>>>>>   if ($vf->coord_system_name eq "chromosome"){
>>>>> 
>>>>> my $type=$vf->is_somatic;
>>>>> if ($type==0){$type='germline';} else {$type='somatic';};
>>>>> 
>>>>> 
>>>>> my $nearest_genes = $vf->get_nearest_Gene;
>>>>> 
>>>>> if ($nearest_genes){
>>>>> my $gene_name=defined($nearest_genes->external_name) ? $nearest_genes->external_name : 'no_ext_gene_name';
>>>>> my $ENS_ID= defined($nearest_genes->stable_id) ? $nearest_genes->stable_id : 'no_stableID';
>>>>> 
>>>>> print OUTFILE2 $variation_human, "\t",'nearestgene
>>>>> is'.$nearest_genes->external_name, "\t", $gene_name, "\t",$ENS_ID,
>>>>> "\n"; } }
>>>>> 
>>>>> 
>>>>> The very same script works for all other chromosomes  and I cannot understand what is the issue here.
>>>>> This is the last SNP ID which will be printed:
>>> 
>>>>> . The following one: rs398123092 will cause an error.
>>>>> I am using ensembl_v79
>>>>> Bio::EnsEMBL::Registry->load_registry_from_db(
>>>>> -host=>  'mysql-ensembl-mirror.ebi.ac.uk', -user=>'anonymous',
>>>>> -port=>'4240', 'db_version' => 79,);
>>>>> 
>>>>> Thanks for any tips,
>>>>> Nathalie
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Dev mailing list    Dev at ensembl.org
>>>>> Posting guidelines and subscribe/unsubscribe info:
>>>>> http://lists.ensembl.org/mailman/listinfo/dev
>>>>> Ensembl Blog: http://www.ensembl.info/
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Dev mailing list    Dev at ensembl.org
>>>> Posting guidelines and subscribe/unsubscribe info:
>>>> http://lists.ensembl.org/mailman/listinfo/dev
>>>> Ensembl Blog: http://www.ensembl.info/
>>> 
>>> _______________________________________________
>>> Dev mailing list    Dev at ensembl.org
>>> Posting guidelines and subscribe/unsubscribe info:
>>> http://lists.ensembl.org/mailman/listinfo/dev
>>> Ensembl Blog: http://www.ensembl.info/
>> 
>> 
>> _______________________________________________
>> Dev mailing list    Dev at ensembl.org
>> Posting guidelines and subscribe/unsubscribe info: http://lists.ensembl.org/mailman/listinfo/dev
>> Ensembl Blog: http://www.ensembl.info/
>> ________________________________
>> This message (including any attachments) may contain confidential, proprietary, privileged and/or private information. The information is intended to be for the use of the individual or entity designated above. If you are not the intended recipient of this message, please notify the sender immediately, and delete the message and any attachments. Any disclosure, reproduction, distribution or other use of this message or any attachments by an individual or entity other than the intended recipient is prohibited.
>> 
>> _______________________________________________
>> Dev mailing list    Dev at ensembl.org
>> Posting guidelines and subscribe/unsubscribe info: http://lists.ensembl.org/mailman/listinfo/dev
>> Ensembl Blog: http://www.ensembl.info/
> 
> 
> _______________________________________________
> Dev mailing list    Dev at ensembl.org
> Posting guidelines and subscribe/unsubscribe info: http://lists.ensembl.org/mailman/listinfo/dev
> Ensembl Blog: http://www.ensembl.info/





More information about the Dev mailing list