Like you, I think the current implementation is a bit confusing.

But at least we can get the original error in the handler. This is useful for both logging and troubleshooting errors. But your solution doesn't take this into account.

Perhaps InternalServerError should be tagged with the original error.

Note, though, that the implementation above will forward the original error when the error handler is installed on 500.

I'm sorry to have misunderstood your solution. I think a test case for the handler of InternalServerError can help us understand your solution more easily.

This assertion is actually already present in

Oh, I see. I only read the codes in your patch. Please forgive me for wasting your precious time!

I mean, now that you mention it, though, I do think it would be a better API if InternalServerError had some reference to the actual original exception. That would likely constitute a breaking API change, though, whereas this might just barely be okay.

Yes, I quite agree with you.

Perhaps InternalServerError should be tagged with the original error.

While I understand the results of this, it's making the code harder to follow for me. Based on previous discussions in PRs that led to where we are now, it seems that it was intended that 500 and InternalServerError were aliases that behave the same way.

Instead, based on your discussions, I went the other direction and made it consistent. 500 and InternalServerError handlers always received InternalServerError, and also add an original_exception attribute. While this could result in some less-specific generic error messages if an application with the old behavior upgrades, I think the behavior becoming easier to reason about is worth it.

Thanks for discussing and working on this! Closing in favor of #3266