A potential fix for messy error box when Error is KeyError

[dafnapension]

BEFORE:
error_box_main.pdf

AFTER:
error_box_fixed.pdf

[dafnapension]

An example from test_error_context_with_context_object:

and from test_error_context_without_object:

[elronbandel]

A very annoying bug indeed. I tried to fix it in the past but hit a wall: currently the new error context messages are not affecting the error trace, your fix does affect it. Im not sure what is more important good error message or good error trace, but if you could solve it in a way both are optimized it will be much better.

Maybe the fix should be not to raise KeyError to begin with?

[dafnapension]

Hi @elronbandel ,
KeyError jumps off "by itself" (by python and not by unitxt) in cases like in here: a given string is not found in a dict (that the string is supposed to be one of its keys).

I changed to return an extension of KeyError that prints out its args not as a constant string, but obeying the \n -s.
As an extension, it does return true for isinstance(e, KeyError) and hence no change in test_error_utils.
It will affect a piece of code expecting this error in the form of if type(e) == KeyError:.

[elronbandel]

So what does the error trace look like now? is it of the original error?

my suggestion was to wrap the problematic external code with:

try:
     # call to external code that raises key error
except KeyError as e:
    raise RuntimeError("Key was not found: {e}")

but this wrapping has to be write on top of the problematic code, so the error trace leads to the exact point of error.

[dafnapension]

Hi @elronbandel , I attached the full notebook for you to see both traces. Are these close enough?

[dafnapension]

HI @elronbandel ,
Effectively, I imbedded this piece of code that you suggested -- inside your error_context

I am not sure I understand whether you consider this "right on top of the problematic code,".
If not - then forget it. I think that exact trace is most important. More than a well organized error box.