try/except and fastapi-problem

[dineshbvadhia]

My fastapi code is littered with try/except clauses to capture exceptions eg.

try:
    do_stuff()
    return stuff
except Exception:
    raise RequestValidationError(f'This stuff is odd.')

Does using fastapi-problem's add_exception_handler mean the try/except clauses can be dropped?

[EdgyEdgemond]

If an exception is raised, and you would like to do something specific, you can try/except/do something. if you just want to convert the error into a response for the user you can let the exception raise, this will trigger a 500 error response if its not an internally raised Problem subclass.

[EdgyEdgemond]

try:
    a = call_func()
except ValueError:
    a = 0

return a

If a ValueError occurs the code will continue, any other exception will bubble up and get converted to a JsonResponse for the user

[dineshbvadhia]

I don't want to do anything specific about internal errors in try/except blocks which are not Problem subclasses. Only to capture (and log) these errors.

To simulate these internal errors, placing print(1/0) in various parts of the code base generates a json 500 error message for the user. This is great.

But at the server, it generates a chained traceback. I want to capture the traceback at the error source. Can this done in a general way?

The code base is mostly of the form:

try:
    do_this()
except Exception as exc:
    raise exc
    
if <something>:
    do_that()
else:
    raise RequestValidationError
    
try:
    do_other()
except:
    raise RequestValidationError

[dineshbvadhia]

Is this what the pre-hook is for?

[EdgyEdgemond]

I'm not sure i understand the question here, if you want to capture and log unexpected errors, this already occurs in the exception handler.

If you are catching errors and raising different errors you can use raise Exception from e format to maintain the exception chain, this is standard python syntax, not related to fastapi-problem specifically.