Project

General

Profile

Support #9768

art::FindManyP throws if art::Handle is invalid

Added by Tingjun Yang about 5 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Navigation
Target version:
-
Start date:
07/30/2015
Due date:
% Done:

0%

Estimated time:
Scope:
Experiment:
LBNE
SSI Package:
art
Duration:

Description

Dear artists,

I use the following code to get showers and hits associated with showers:

// ShowerList handle
art::Handle< std::vector<recob::Shower> > showerListHandle;
std::vector<art::Ptr<recob::Shower> > showerlist;
if (evt.getByLabel(fShowerModuleLabel,showerListHandle))
  art::fill_ptr_vector(showerlist, showerListHandle); 
art::FindManyP<recob::Hit> fmsht(showerListHandle,evt, fShowerModuleLabel);

FindManyP will show an exception of ProductNotFound if showerListHandle is invalid. If I insert 

if (!showerListHandle.isValid()) showerListHandle.clear();

before FindManyP, I do not get the exception.

Would it be ok to make FindManyP (and others Find*) not show when art::Handle is invalid? One can check if the association is valid later.

Tingjun

Related issues

Related to art - Bug #9769: Dereferencing a default-constructed (or cleared) Handle does not throwClosed07/30/2015

History

#1 Updated by Tingjun Yang about 5 years ago

art version v1_15_01

#2 Updated by Christopher Green about 5 years ago

  • Related to Bug #9769: Dereferencing a default-constructed (or cleared) Handle does not throw added

#3 Updated by Christopher Green about 5 years ago

  • Description updated (diff)
  • Category set to Navigation
  • SSI Package art added
  • SSI Package deleted ()

Hi,

Unfortunately, the method you are using to avoid throwing an exception actually exposes a bug in art::Handle that results in a null pointer dereference, which I have reported as issue #9769 and attached to this issue. If it doesn't cause an outright crash, it could cause hard-to-diagnose issues with memory corruption and bad results down the line.

It would be relatively straightforward to delay the exception throw until someone attempts to use a FindOne or FindMany without first checking its validity, but I think it is important to continue to preserve the difference between an empty collection and one that could not be found as specified.

#4 Updated by Tingjun Yang about 5 years ago

Hi Chris,

I understand it is important to preserve the difference between an empty collection and one that does not exist. But I find it inconvenient if FindMany throws at all because it means I have to put everything into an if block:
if (showerListHandle.isValid()){
art::FindManyP<recob::Hit> fmsht(showerListHandle,evt, fShowerModuleLabel);
Loop over showers and get associations...
}
But I guess I can start coding in this way.

Tingjun

#5 Updated by Kyle Knoepfel almost 5 years ago

  • Tracker changed from Idea to Support
  • Status changed from New to Feedback

We would like to discuss with you some possibilities for your particular use case. Could you stop by so we could understand better what it is you need?

#6 Updated by Kyle Knoepfel over 4 years ago

  • Subject changed from art::FindManyP shows if art::Handle is invalid to art::FindManyP throws if art::Handle is invalid

#7 Updated by Kyle Knoepfel over 4 years ago

  • Status changed from Feedback to Closed

Closed per author feedback.

Also available in: Atom PDF