First, a pure stylistic suggestion:

The idea is to not use an explicit block for the else case by default to reduce the amount of blocks (indented code). Then there is a choice what to put inside the remaining block - here I followed the idea to keep the "good"/"healthy" code path without blocks and the "exceptional"/"special cases" in the conditional block. At least to me, this style improves readability. What do you think?

The next comment may very well be out of scope of this PR, but I make it anyways, while at it; if you like it, we can pick it up later:

Using logs to communicate program logic errors feels off. I would like to propose to promote the warning into a "precondition check". There are two standard approaches to do this that come to mind:

Option A: throw

void FairRun::FillEventHeader()
{
    if (!fSource) {
        throw std::runtime_error("fSource not set"); // should probably be a different exception type
    }

    fSource->FillEventHeader(fEvtHeader);
}

This could fit, if FairRoot in general wants to make much more use of exceptions.

Option B: assert

void FairRun::FillEventHeader()
{
    assert(fSource);

    fSource->FillEventHeader(fEvtHeader);
}

This would be the less invasive version, but will mostly be similar to a comment as people usually do not work with debug builds at all. At the end, this may also be subject to a project-wide style discussion on how to express function preconditions.

For reference, the C++ Core Guideline recommends adopting Expect() (and Ensure()), see I.5, I.6, I.7, and I.8

Thanks for reminding me about reducing indented blocks! (It's actually one reason, why I like 80 column rules: It forces people to avoid too much indentation.)

And I like the style of "check things and exit/return early".

About pre-conditions, etc:

• I don't know, whether fSource not being set is actually a valid scenario. I doubt it, but I am really not sure. So before going to LOG(error) or throw I wanted to increase awareness a bit.
• Yes, I would prefer exceptions for this type of error. People can catch them, handle them, etc. Yes, we probably should discuss this in a broader community.
• I haven't looked deeper into Expects, but this sounds like a nice thing!

I don't know, whether fSource not being set is actually a valid scenario. I doubt it,

This would support that it should be understood as a classic pre-condition. I was looking at it from this angle: What can the user do to get rid of this warning?! Probably mostly by a code change. Which is a design time activity, so I would want to consider design time checks/hints. Since we also interpret everything optionally, it becomes more complex what/when design time is and which type of check is the best. but anyways, out of scope of this PR. LGTM

I have two suggestions:

1. Always prefer exceptions to abort
   Using exception could lead to stack unwinding, releasing memories allocated in heap before the operating system kills the program. On the other hand, abort (or other functions that calls it in the end, such as assert and std::terminate) doesn't do any stack unwinding and leave the memory cleaning to the operating system. Some operating systems do not do the cleaning job and there could be memory leak. Of course there are many situations when we have no choice but to call abort.

2. Include MS/GSL library into FairSoft?
   I don't know when FairRoot will move to C++20 or even C++23. But some features in GSL are really useful. Contract (expect and ensure) is one of them. gsl::span, gsl::not_null, Range are also pretty useful.