[df] Throw on JIT helper compilation failure instead of crashing

[guitargeek]

Check the EErrorCode returned by ProcessLine() and verify that each helper's DeclId_t is non-null, throwing std::runtime_error in either case so users get a proper exception instead of a hard crash.

Closes #21659

I'm going for reports related to jupyter notebooks now, which is why I tacked this issue.

[github-actions]

Test Results

    22 files      22 suites   3d 7h 51m 30s ⏱️
 3 847 tests  3 847 ✅ 0 💤 0 ❌
75 989 runs  75 989 ✅ 0 💤 0 ❌

Results for commit 29aa52b.

[vepadulano]

I was looking into this but then I found out that for seemingly simple compilation failures cling is not able to actually report back the error to consumer code, see #22235 . I wonder how this PR is working?

[guitargeek]

Well I can't give you more detail about it, sorry! I just saw the error code interface getting used in JupyROOT in the ProcessLineWrapper and re-used the pattern.

[guitargeek]

I was looking into this but then I found out that for seemingly simple compilation failures cling is not able to actually report back the error to consumer code, see #22235 . I wonder how this PR is working?

It occurred to me after reading your discussion in the GitHub issue that you maybe meant "I wonder how this PR is working on macOS and Windows".

In that case, the answer is that it doesn't. The added test is behind the following preprocessor checks, that already existed to guard other tests that validate the throwing of exceptions:

// throwing exceptions from jitted code cause problems on windows and MacOS+M1
#if !defined(_MSC_VER) || defined(R__ENABLE_BROKEN_WIN_TESTS)
#if !(defined(R__MACOSX) && defined(__arm64__))