We could have a base exception e.g.
class APIException:
status_code: int
user_message: str
Then existing custom exceptions can override these (along with the usual message specified in the constructor). Then a custom exception handler can be used to catch all such exceptions and log/return their status code and user message (without any IDs), effectively recreating sections like
|
except LeafCategoryError as exc: |
|
message = "Adding a catalogue category to a leaf parent catalogue category is not allowed" |
|
logger.exception(message) |
|
raise HTTPException(status_code=status.HTTP_409_CONFLICT, detail=message) from exc |
But just by relying on
raise LeafCategoryError, in this case the whole try/catch could be removed.
We could have a base exception e.g.
Then existing custom exceptions can override these (along with the usual message specified in the constructor). Then a custom exception handler can be used to catch all such exceptions and log/return their status code and user message (without any IDs), effectively recreating sections like
inventory-management-system-api/inventory_management_system_api/routers/v1/catalogue_category.py
Lines 135 to 138 in 3a1d6cb
But just by relying on
raise LeafCategoryError, in this case the whole try/catch could be removed.