by Kyle Knoepfel
Chris Backhouse, Patrick Gartung, Rob Kutschke, Adam Lyon, Brian Rebel, Erica Snider
artists: Lynn Garren, Chris Green, Kyle Knoepfel, Marc Paterno
Bug #9363 : Brian reported an assertion failure when trying to read multiple LArIAT events with the nutools EventDisplay. The error was that an unnecessary (and sometimes incorrect) precondition was being checked. This was resolved by removing the assertion.
The bug fix will be slated for release 1.15.01. Brian and Erica (LArSoft) were amenable to placing the fix in the 1.15 series and not worrying about producing a 1.14.04 version.
Chris suspected 1.15.01 could be tagged by the end of the day, and Lynn could start building tomorrow. Rob will update the toyExperiment package once the 1.15.01 release is out.
Feature #8655: Chris asked if Mu2e has had the chance to test the new FHiCL enhancements. Rob said not yet, but Andrei is on vacation and will get back on Monday.
Feature #9378: Change default exception handling
Request from Herb Greenlee of MicroBooNE to change the behavior of the default exception handling. Most exceptions default to rethrow, which attempts a graceful shutdown of the system. However, some exceptions like “ProductNotFound” will skip the event instead. The initiating event here was #9348, where an invalid service handle request resulted in skipping an event instead of the desired behavior, which was to rethrow.
Chris mentioned that exception handling is configurable:
— from the command-line: ‘–rethrow-all’ overrides all FHiCL configurations and rethrows all exceptions, or
— setting ‘services.scheduler.defaultExceptions’ to ‘false’ rethrows all exceptions, but is overridable for specific types of errors
Consensus reached that email should be sent to the stakeholders for their opinion on which exceptions, whose current default behavior is to skip the event, should instead by handled by rethrowing the exception.
Again, it should be emphasized that this proposal applies only to default handling of exception throwing.
Chris mentioned that exception handling behavior is based on the category name, and not the type. It is therefore possible for a user to declare a differently-typed exception (that inherits from cet::coded_exception) and if it is thrown it may be handled in the same way as another exception that has the same name.
Chris thought he would be able to introduce a new exception error (‘ServiceNotFound’) in time for the 1.15.01 release.