Add K4_GAUDI_CHECK macro.

[scott-snyder]

Add a macro to reduce repetitive code involved in checking for error return statuses in Gaudi components.

This allows for example to replace code like

  if (!m_cellPositionsTool.retrieve()) {
    error() << "Unable to retrieve cell positions tool." << endmsg;
    return StatusCode::FAILURE;
  }

with

  K4_GAUDI_CHECK( m_cellPositionsTool.retrieve() );

BEGINRELEASENOTES

• Add macro K4_GAUDI_CHECK (in k4FWCore/k4_check.h) to reduce the boilerplate involved in checking Gaudi return status. If its argument is false, the macro will emit and error and return StatusCode::FAILURE.
  ENDRELEASENOTES

[tmadlener]

I see the utility of this, but I think we might need to

• Adapt the name. K4_CHECK almost implies that it's usable anywhere in Key4hep, but it only works within Algorithms (which is going to be a large part of things in Key4hep). Maybe K4_GAUDI_CHECK, but I am also not entirely happy with that.
• Make it accept a message argument or provide a version that takes a user message and adds that to the error message as well.

[scott-snyder]

For a little context, this is a much-simplified version of the
[ATH_]CHECK macros we've used in ATLAS for a long time now:

https://gitlab.cern.ch/atlas/athena/-/blob/main/Control/AthenaKernel/AthenaKernel/errorcheck.h?ref_type=heads
https://gitlab.cern.ch/atlas/athena/-/blob/main/Control/AthenaBaseComps/AthenaBaseComps/AthCheckMacros.h?ref_type=heads

(Having both names is historical; we'd use just ATH_CHECK if we were doing
it over.)

You're right in that this can only be used in a Gaudi component. In ATLAS,
we have other variants of the macro that can be used in other contexts.
In practice, however, this is rare, so i didn't include that functionality
at this point. However, i will rename as suggested.

I could add an option to give a custom error message. However,
at ATLAS i've never really felt the need for that (giving the failed expression
along with the line number is generally sufficient), so i'd prefer to keep
this simple to start with and extend later if desired.

(In passing, i have some pending calorimeter changes which will use this.)

[tmadlener]

I could add an option to give a custom error message. However,
at ATLAS i've never really felt the need for that (giving the failed expression
along with the line number is generally sufficient), so i'd prefer to keep
this simple to start with and extend later if desired.

Yeah, that makes sense. Usually one of the first thing you do in any case is to grep for the error message and hope for only a handful of results. Also if it allows us to keep boost preprocessor out for now, I am happy.

[scott-snyder]

Squashed.

[jmcarcell]

If this is used in ATLAS and now here, doesn't it make sense that we should have something like this in Gaudi? In some cases we do not always return. I see that in ATLAS every possible one is defined. How does it look in ATLAS, is it only these macros?

[scott-snyder]

If this is used in ATLAS and now here, doesn't it make sense that we should have something like this in Gaudi?

We could consider that, i guess, but using a project-specific name allows for customization later, eg., for error reporting (a la ATLAS).

In some cases we do not always return. I see that in ATLAS every possible one is defined. How does it look in ATLAS, is it only these macros?

Not quite sure what you're getting at here. Yes, one sometimes need to be aware that the *CHECK macros can return, not so much in initialize() (where they're mostly used) but more so in event processing.

ATH_CHECK is used throughout Atlas code:

https://acode-browser1.usatlas.bnl.gov/lxr/search?%21v=head&_filestring=&_string=ATH_CHECK

as I said mostly in initialize() but in plenty of other places as well. Other variants such as *CHECK_RECOVERABLE and *CHECK_WITH_CONTEXT have a few uses, but are dwarfed by the plain ATH_CHECK.