Does anyone know if you can disable sending server side exceptions to the client? I’m mostly concerned about what information is being disclosed from the “secure” side of the app.
ie. LookupError(f"{user_id} not found in Users table") is a pretty helpful exception, but I just leaked user_id down to the client from server code.
I know that I can go around and place client side default error handlers but that does not stop the exception from heading over to the client. Thus exposing server side information to the client if one is not careful.
Could exceptions be sent to the client in debug environments only?
How are other people handling having good error reporting without leaking information?
2 Likes
I don’t know of any built-in way to do that.
But you could write a decorator that has a try/except and logs server side exceptions rather than propagating them to the client. Put that on any server callable function and you’d catch anything that might propagate to the client.
If you’re using models, be aware that some of the model methods execute on the server and you’d need to handle those, too.
2 Likes
And if you’re using any database objects (tables, views, or rows) directly on the Client, then that can result in “implicit” server calls, to perform the database operations your code requests. These, too, can generate exceptions.
The only way to prevent exceptions from coming in that way, is to just not do that, and do everything through explicit server calls, or through Models’ server-side code.
Edit: explicit server calls have the advantage that they can return error “codes” of your own devising, instead. This can be handy when your Client code needs to know that something has gone wrong, and alter its response accordingly.
2 Likes
Thanks @jshaffstall and @p.colbert , If the scope of the issues was limited to just callables then yeah, it seems pretty tractable to make my own server.callable decorator that captures Exceptions.
Hahah… I guess the really dumb, but ultimately effective solution would be to just wrap entire modules with a try except block… But that feel so wrong.
The other downside to capturing the exception is you can no longer filter for sessions with errors in the app logs.
Yeah, you’d have to write your own error logs, as @jshaffstall suggests.
A framework for that has appeared very recently in this Forum.
The flip side of logging your own errors, as usual, is the ability to customize the behavior. Got an especially important client? Get notified of their errors sooner. Are there patterns in the errors? The errors’ context-values may lend a clue.