Project

General

Profile

Bug #24303

Standard error messages should refer to the correct FHiCL parameter names

Added by John Freeman 3 months ago. Updated 2 months ago.

Status:
New
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 2 months ago

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

History

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

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



Also available in: Atom PDF