Bug #24303

Standard error messages should refer to the correct FHiCL parameter names

Added by John Freeman 8 months ago. Updated 4 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


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
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 7 months ago

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


#1 Updated by Eric Flumerfelt 8 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 8 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 8 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 7 months ago

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

#5 Updated by Eric Flumerfelt 4 months ago

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

Also available in: Atom PDF