Custom raise message helper

[muellerzr]

Raise with message helper

What does this add?

This PR adds a helper function that will allow a user to easily add custom messages to already existing Exceptions

Who is it for?

Developers who want to provide clearer messages for errors

Why is it needed?

I constantly see myself going through the same repeating patterns when writing better error logs for Exceptions, and this PR improves this frustration by writing a quick util for it

What parts of the API does this impact?

User-facing:

Adds a new raise_with_msg function that takes in an exception, a message, and a boolean of whether to append the new message to the original exception args (e.args) or to override them completely with the new message

Internal structure:

None, however after this PR it will be propagated into fastai for the debugging errors/logs

Basic Usage Example(s):

Before:

try: dosomething()
except Exception as e:
    e.args = ["Some custom error message"]
    raise

After:

try: dosomething()
except Exception as e: raise_with_msg(e, "Some custom error message")

When would I use it, and when wouldn't I?

You'd use this specifically when the default error/exception might need to be changed, and putting the message in the base exception will not do. Such as when there are multiple triggers for the same exception, but depending on where it was called from their context could be slightly different

Does a similar feature exist? If so, why is this better?

No

cc @hamelsmu @jph00

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[jph00]

Message ID: ***@***.***>Thanks! How does the stack-trace look in the "before" and "after" versions of this change? I'm guessing the new approach might have a deeper stack? Would it help the stack trace to add `from None` to the end of the `raise` block?

[muellerzr]

@jph00 it did by one frame due to the nested callings. Sadly not even doing the from None helped because it'll still trace to where we called it. Instead this is a func that now just modifies e.args and returns it. Aka the earlier example is now:

try: dosomething()
except Exception as e: raise modify_exception(e, "Some custom error message")

I'd monkey-patch exception but sadly we can't do that since it's base C.

If we're fine with one extra frame in the midst of our error finding I can have it be raised in the func itself, but otherwise sadly not 😄

[jph00]

I think that's a better approach - thanks