Exceptions API#

fastapi_restly.exc defines the public exception hierarchy: configuration errors raised when the framework is misused at setup, and request-time HTTP errors that subclass fastapi.HTTPException.

Public exception hierarchy for FastAPI-Restly.

Two families:

Configuration-time errors (RestlyError / RestlyConfigurationError) raised when the framework is misused before/at setup.
Request-time HTTP errors (NotFound / Forbidden / Conflict / BadQueryParam) raised while handling a request. These subclass fastapi.HTTPException, so the default responses are identical to raising HTTPException directly – but a user can app.add_exception_handler(fr.exc.NotFound, ...) to reshape Restly’s errors distinctly (e.g. into RFC 7807 problem+json).

exception fastapi_restly.exc.BadQueryParam(detail: object | None = None, **kwargs: object)#

Bases: RestlyHTTPError

HTTP 400 – an invalid filter/sort/pagination query parameter.

default_detail: str = 'Invalid query parameter'#

status_code: int = 400#

exception fastapi_restly.exc.Conflict(detail: object | None = None, **kwargs: object)#

Bases: RestlyHTTPError

HTTP 409 – the request conflicts with the current resource state.

default_detail: str = 'Conflict'#

status_code: int = 409#

exception fastapi_restly.exc.Forbidden(detail: object | None = None, **kwargs: object)#

Bases: RestlyHTTPError

HTTP 403 – the request is not authorized.

default_detail: str = 'Forbidden'#

status_code: int = 403#

exception fastapi_restly.exc.NotFound(detail: object | None = None, **kwargs: object)#

Bases: RestlyHTTPError

HTTP 404 – the requested resource does not exist (or is not visible).

default_detail: str = 'Not found'#

status_code: int = 404#

exception fastapi_restly.exc.RestlyConfigurationError#

Bases: RestlyError

Raised when Restly is used before required configuration is available.

exception fastapi_restly.exc.RestlyDuplicateSchemaNameWarning#

Bases: UserWarning

Emitted when more than one class in the OpenAPI spec has the same name.

OpenAPI keeps all classes in one list, by name. So pydantic shows the classes under long names that can change, such as app__tasks__views__TaskCreate, and generated clients use these names as type names. The warning names the classes and the views that use them.

Restly checks the spec each time the app builds it. It knows the app when you pass it to configure() or configure_tests(), or when you include a view on the app itself. Then the check also covers the views that you include on an APIRouter. There is no setting that turns the check off. A project test can turn the warning into an error with warnings.simplefilter("error", RestlyDuplicateSchemaNameWarning).

exception fastapi_restly.exc.RestlyError#

Bases: Exception

Base class for FastAPI-Restly framework errors.

exception fastapi_restly.exc.RestlyHTTPError(detail: object | None = None, **kwargs: object)#

Bases: HTTPException

Base for Restly’s request-time HTTP errors. Subclasses set a status.

default_detail: str = 'Error'#

status_code: int = 500#

exception fastapi_restly.exc.RestlyMisuseWarning#

Bases: UserWarning

Emitted at view registration for common framework-misuse patterns.

Opt-in: enable with fr.configure(warn_on_misuse=True). When a view class is registered via include_view, the framework then flags the dominant misuses – overriding an endpoint method (<verb>_endpoint) where a business-method override was meant, calling session.commit() directly in a view method, hand-rolling a CRUD route set on a bare View instead of subclassing RestView / AsyncRestView, and typing a scalar foreign-key column (post_id) as an IDRef / IDSchema reference instead of fr.MustExist[int, Model].

exception fastapi_restly.exc.RestlyUncommittedChangesWarning#

Bases: UserWarning

Emitted when a request finishes with uncommitted changes in the session.

The write handlers own the commit, so a custom write route that flushes (e.g. via save_object) but never commits has its changes silently rolled back when the session closes. The fix is almost always to commit: bracket the mutation with write_action(...) (the framework then runs the commit), or reuse a handle_<verb> handler. A route that intentionally rolls back (a validate-then-rollback dry run) can suppress the warning for just that request with session.info["_fr_suppress_uncommitted"] = True.