Project

General

Profile

Bug #24303

Standard error messages should refer to the correct FHiCL parameter names

Added by John Freeman 11 months ago. Updated 7 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
04/10/2020
Due date:
% Done:

0%

Estimated time:
Experiment:
-
Co-Assignees:
Duration:

Description

Working with Bill Badgett to get his Icarus setup running, we bumped into the following error message in a boardreader:

Error in CommandableFragmentGenerator: use_data_thread must be true when request_mode is not "Ignored"!

However, when he set "use_data_thread: true" in the boardreader's FHiCL, the problem persisted. This is because the FHiCL parameter he needed to set to true was in fact "separate_data_thread". From CommandableFragmentGenerator.cc:
useDataThread_(ps.get<bool>("separate_data_thread", false))

We should fix this message, and any other messages, which don't refer to the correct FHiCL parameter name.

Associated revisions

Revision fffadcd6 (diff)
Added by Eric Flumerfelt 10 months ago

First-order fix for Issue #24303 by changing the variable name in the message.

History

#1 Updated by Eric Flumerfelt 11 months ago

Should we define the parameter names as const statics or macros to ensure that they're correct everywhere they appear? (I'm thinking parameter structs, Doxygen, constructor/config methods, and messages)

#2 Updated by John Freeman 11 months ago

Good idea, though I think it's fair to say we want to get away from macros as much as possible. One way to structure this is to have a mapping between what a parameter's name in the code is, and what its FHiCL name is. E.g., something like:

ParameterMapping["useDataThread_"] = "separate_data_thread" 

so then you could have an error message like the following:

if (!useDataThread_) {
 latest_exception_report_ = "Error in CommandableFragmentGenerator: " + ParameterMapping["useDataThread_"] + " must be true when request_mode is not \"Ignored\"!";

#3 Updated by John Freeman 11 months ago

...although thinking about it a little bit more, in the approach I suggested it would be harder for someone reading the code to figure out what error message to look for in the logfiles since the "user-facing" variable name would get obscured in the code. Just something to factor in.

#4 Updated by Eric Flumerfelt 10 months ago

First-order solution (fixing variable name in the message) implemented on artdaq:bugfix/24303_FixErrorMessages

#5 Updated by Eric Flumerfelt 7 months ago

  • Target version set to artdaq v3_09_00
  • Status changed from New to Closed

Also available in: Atom PDF