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:

[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.