Project

General

Profile

Bug #12385

Handle slicing exceptions when throwing

Added by David Dagenhart over 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Category:
Infrastructure
Target version:
Start date:
04/22/2016
Due date:
% Done:

100%

Estimated time:
8.00 h
Spent time:
Occurs In:
Scope:
Internal
Experiment:
LArSoft
SSI Package:
-
Duration:

Description

In the current code, the Handle class in art and gallery
can store an exception using a pointer with type
std::shared_ptr<cet::exception const>. The actual exceptions
that are built have type cet::coded_exception which
has cet::exception as a base class. To throw the
exception Handle uses "throw *whyFailed_;" which slices
the exception and throws an exception with the type of the
base class. In the current code, cet::exception has a virtual
function rethrow but it is private, coded_exception
does not override it, and Handle does not use it.

No users have reported the problem and its impact is
minor. If you try to catch the exception you must use
the base class type and the extra info which is originally
in the derived class has been sliced away so it is not
possible to access it.

There are different options available as to how to fix
this.

History

#1 Updated by Kyle Knoepfel over 4 years ago

  • Category set to Infrastructure
  • Status changed from New to Assigned
  • Assignee set to Christopher Green
  • Estimated time set to 8.00 h
  • Experiment LArSoft added
  • Experiment deleted (-)
  • SSI Package cetlib added
  • SSI Package deleted ()

#2 Updated by Christopher Green over 4 years ago

  • Status changed from Assigned to Resolved
  • Target version set to 2.00.01
  • % Done changed from 0 to 100
  • SSI Package - added
  • SSI Package deleted (cetlib)

Fixed minimally by replacing std::shared_ptr<cet::exception> with std::shared_ptr<art::Exception> with commits cetlib:be9f8e8, canvas:549803c, art:8a1d7d4 and gallery:d66e9e4.

The solution using std::exception_ptr had the drawback that calling std::make_exception_ptr() caused an exception throw and catch. Since it is our policy to avoid throwing exceptions as normal flow control, this was deemed unacceptable as a solution.

In addition to the aforementioned change, a couple of other cases of exceptions in non-exceptional circumstances were also removed, in commit art:fd42ce9.

#3 Updated by Kyle Knoepfel about 4 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF