Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As you know, I have been looking at exception handling a lot lately (see #2162). This is an attempt to make exception handling even more consistent across an application and more developer-friendly. Yes, we have
@app.exception
to allow you to format exceptions. But, especially if you have lots of different types of exceptions, it often becomes overwhelming to create a set of consistent error messaging.#2216 took a nice step forward with this:
But this lacks two things:
With this PR, we can add some information to the exception when we raise it to help us format the error message:
In a somewhat similar API to logging, we have the ability to bring
extra
meta to the exception instance. Thisextra
info object should be suppressed when in production mode, but we allow it to be displayed in debug mode.Getting back to item 2 from above: The ability to add additional context to an error message
This is particularly useful when creating microservices or an API that you intend to pass error messages back in JSON format. In this use case, we want to have some context around the exception beyond just a parseable error message to return details to the client.
This PR also addes a
context
object that is similar to what is used in signals.This is information that we want to always be passed in the error (when it is available). Here is what it should look like in non-debug mode (better naming on this in #2237):
With debug now turned on:
TODO