Improving HTTPException to make it identical to FastAPI's

[papb]

Currently, FastAPI has their own HTTPException which is a subclass of starlette.exceptions.HTTPException.

Previously, the main difference was the fact that Starlette's HTTPException did not support specifying custom headers for the response. Since #1435, this is no longer true.

However, there is still a minor difference.

Is it possible for Starlette to overcome this little difference so that FastAPI no longer needs a custom subclass? It would make things simpler and easier to understand.

Related: tiangolo/fastapi#5418

[Kludex]

I think it's fine the way it is. 👀

Not a big issue, is it? 👀

[papb]

I wouldn't say "big", but I'd say a fix would still be very benefitial from both a maintaing and a documenting perspective. See tiangolo/fastapi#5418. Fixing this would allow the documentation to be greatly simplified, for example by removing the need to do

from starlette.exceptions import HTTPException as StarletteHTTPException
from fastapi import HTTPException

and then just do

from fastapi import HTTPException

It looks like the difference that currently exists is basically unintended, since it's just about a typing annotation. Apparently, although the type hint is str, Starlette's HTTPException already works with any json-able value, since FastAPI does nothing more than changing the type hint:

# From FastAPI
class HTTPException(StarletteHTTPException):
    def __init__(
        self,
        status_code: int,
        detail: Any = None,
        headers: Optional[Dict[str, Any]] = None,
    ) -> None:
        super().__init__(status_code=status_code, detail=detail, headers=headers)

[tiangolo]

I actually agree with @Kludex that Starlette shouldn't change. In fact, I want to make FastAPI behave like Starlette and add another field for the JSON data, because I discovered there's an RFC for HTTP errors that says that detail should be a string.