Project

General

Profile

Idea #12778

LArSoft needs an error handling policy

Added by Ruth Pordes over 3 years ago. Updated 21 days ago.

Status:
Closed
Priority:
Normal
Category:
Documentation
Target version:
-
Start date:
05/26/2016
Due date:
% Done:

0%

Estimated time:
Experiment:
-
Duration:

Description

LArSoft needs an error handling policy,see http://cd-docdb.fnal.gov/cgi-bin/ShowDocument?docid=5766


Related issues

Related to art - Support #20530: Provide error-handling pageClosed08/06/2018

History

#1 Updated by Katherine Lato over 3 years ago

This also came up at the LArSoft Usability Workshop - Currently, LArSoft doesn't have guidance on the difference between a warning versus an error, and how the program should respond. May want to put more thought into error-handling.

#2 Updated by Gianluca Petrillo over 3 years ago

  • Status changed from New to Assigned

#3 Updated by Katherine Lato about 3 years ago

  • Status changed from Assigned to Accepted
  • Assignee deleted (Erica Snider)
  • Target version set to 2017-1-quarter

This is something to consider with the rest of the 'next batch' of work.

#4 Updated by Katherine Lato almost 3 years ago

  • Category set to Documentation
  • Status changed from Accepted to Assigned
  • Assignee set to Katherine Lato
  • Target version deleted (2017-1-quarter)

from the document:

3.5. Error handling in LArSoft modules

Type: LArSoft coding guidelines

Issue: The definition of error conditions, and the actions taken in response (including whether to throw an exception) is completely defined by code authors.

Owner: LArSoft

Recommendation: LArSoft needs an error handling policy, saying how module code should respond to error conditions, what exceptions should be thrown, what should be reported to the framework, and how to configure the framework to respond appropriately. The policy should also prescribe what common conditions constitute an “error” versus a “warning”, etc. An education campaign will then be needed to disseminate this information.

After discussion with Marc Paterno:
If the caller of the module knows what to do if it doesn’t work, then returning a status code is probably enough.
If the caller of the module isn’t likely to know what to do, throw an exception by using the art::Exception class. Pick the error code that is closest. Can add more details in an error message. Whether the error is treated as fatal is up to the framework.

Still need work on:
The policy should also prescribe what common conditions constitute an “error” versus a “warning”, etc. An education campaign will then be needed to disseminate this information.

#6 Updated by Katherine Lato about 1 year ago

#7 Updated by Katherine Lato 25 days ago

  • Status changed from Assigned to Resolved

#8 Updated by Kyle Knoepfel 21 days ago

  • Status changed from Resolved to Closed
  • Subject changed from LArSoft needs an error handling policy, to LArSoft needs an error handling policy


Also available in: Atom PDF