Abstracts error handling in the tritonfrontend/_api away with the decorator @handle_triton_error. This removes the need to wrap every function in _api/_<service>.py with a try: ... catch: ... manually.
Side Note for the dunder functions:
For _api/_<service>.py::__enter__(): Since this method just calls start() and start() has @handle_triton_error, any error that occurs in __enter__() will be handled by the desired try: ... catch: ....
For _api/_<service>.py::__exit__(self, exc_type, exc_value, traceback): If an exception occurs when inside the context, it will gracefully call exit. But to be captured by @handle_triton_error it must be thrown again.
Where should the reviewer start?
Look at src/python/tritonfrontend/_api/_error_mapping.py
Test plan:
Ran with existing test cases L0_python_api to verify that errors are being handled identically.
What does the PR do?
Abstracts error handling in the
tritonfrontend/_apiaway with the decorator@handle_triton_error. This removes the need to wrap every function in_api/_<service>.pywith atry: ... catch: ...manually.Side Note for the dunder functions: For
_api/_<service>.py::__enter__(): Since this method just callsstart()andstart()has@handle_triton_error, any error that occurs in__enter__()will be handled by the desiredtry: ... catch: .... For_api/_<service>.py::__exit__(self, exc_type, exc_value, traceback): If an exception occurs when inside the context, it will gracefully call exit. But to be captured by@handle_triton_errorit must be thrown again.Where should the reviewer start?
Look at
src/python/tritonfrontend/_api/_error_mapping.pyTest plan:
Ran with existing test cases
L0_python_apito verify that errors are being handled identically.