You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I realized that we are giving an ugly python stacktrace back to the user after the pyCRUD migration work.
In the top of the procedure, we should catch any exception and return back the exception's text rather than raise an unhandled exception. Now, the user sees:
Traceback (most recent call last):
File "_udf_code.py", line 12, in run_delete
File "/home/udf/27672521534251782/crud.zip/crud/wh_sched.py", line 285, in delete_warehouse_schedule
raise ValueError("Cannot delete the last schedule for a warehouse.")
ValueError: Cannot delete the last schedule for a warehouse.
in function DELETE_WAREHOUSE_SCHEDULE with handler run_delete
They could simply see the following instead:
Cannot delete the last schedule for a warehouse.
Related: we indicate an "error" right now if the procedure does not return NULL. Maybe we should be returning a proper exception? Not sure what is "normal" when it comes to non-SQL procedures.
The text was updated successfully, but these errors were encountered:
I realized that we are giving an ugly python stacktrace back to the user after the pyCRUD migration work.
In the top of the procedure, we should catch any exception and return back the exception's text rather than raise an unhandled exception. Now, the user sees:
They could simply see the following instead:
Related: we indicate an "error" right now if the procedure does not return
NULL
. Maybe we should be returning a proper exception? Not sure what is "normal" when it comes to non-SQL procedures.The text was updated successfully, but these errors were encountered: