There is a lot of parameter verification logic inside Pait, so a variety of error conditions will occur.
In order to easily catch and understand exceptions during use, Pait has a simple exception mechanism.
Note
Exceptions of Pait are inherited from PaitBaseException,
and in the event of an exception can use isinstance(exc, PaitBaseException) to determine if the exception is a Pait exception.
In addition, since Pait passes the data to Pydantic for validation, Pydantic related exceptions will be thrown at runtime because the validation fails, you can learn how to use Pydantic exceptions through Error Handling.
1.Pait exception introduction
1.1.TipException
When the program is running, Pait checks and verifies the parameters, and throws an exception if the verification fails.
However, the exception will only flow in Pait and will not be exposed so that the developer will not be able to know which route function threw the exception,
which makes troubleshooting very difficult.
So Pait wraps the exception in a TipException that indicates which route function threw the exception and where it threw it.
If you use an IDE tool such as Pycharm, you can also click on the route to jump to the corresponding place, an example of an exception is as follows:
Through the exception example, can see that the exception is thrown through the gen_tip_exc function,
and the thrown exception information includes the location of the route function.
However, there is a downside to using TipException though,
it causes all exceptions to be TipException needing to get the original exception via TipException.exc.
1.2.Parameter exception
Currently, Pait has 3 types of parameter exceptions, as follows:
Exception
Location
Description
NotFoundFieldException
Plugin Pre Check
Indicates that the corresponding Field cannot be matched, and this exception will not be encountered during normal use.
NotFoundValueException
Execute route function
This exception indicates that the corresponding value cannot be found from the request data. This is a common exception.
FieldValueTypeException
Plugin Pre Check
Indicates that Pait found that the values filled in default, example in Field are illegal, and the user needs to make corrections according to the prompts.
These three exceptions are inherited from PaitBaseParamException, and its source code is as follows:
It can be seen from the code that PaitBaseParamException not only includes error information,
but also includes the name of the parameter that caused the current error.
2.How to use exceptions
2.1.Usage Exception
In CRUD business, exceptions thrown by route functions must be caught, and then an agreed error message is returned for front-end use.
The following is an example code for exception capture:
The exception handling of the api_exception function in the sample code is arranged in a strict order.
It is generally recommended to handle exceptions in this order.
The first highlighted code of the api_exception function is to extract the original exception of TipException.
All subsequent exception handling is for the original exception, so it has the highest priority.
The second highlighted code is to handle all Pait parameter exceptions.
It will extract parameter information and error information and inform the user which parameter has an error.
The third highlighted code handles the verification exception of Pydantic.
It will parse the exception and return the parameter information that failed the verification.
The fourth piece of code handles all exceptions of Pait, which usually occur rarely.
The last step is to handle exceptions in other situations, which may be exceptions defined by the business system.
The last highlighted code is to mount the custom api_exception function into the framework's exception handling callback through the exception mechanism of the Web framework.
Note
Tornado's exception handling is implemented in RequestHandler.
After running the code and calling the curl command can know:
When parameters are missing, an error message indicating that the parameter cannot be found will be returned.
➜~curl"http://127.0.0.1:8000/api/demo"{"code":-1,"msg":"error param:demo_value, Can not found demo_value value"}
When parameter verification fails, the parameter name with verification error will be returned.
The TipExceptions are enabled by default.
If you think that error prompts will consume performance or want to turn off it,
can define the tip_exception_class attribute of ParamHandler as None to turn off exception prompts. code show as below:
The sample code has a total of three modifications:
- The NotTipParamHandler in the first highlighted code is inherited from ParamHandler (or AsyncParamHandler),
which turns off exception tip by setting the tip_exception_class attribute to empty.
- The second piece of highlighting code removes the TipException extraction logic from the api_exception function, as it is not needed now.
- The third piece of highlighted code defines the ParamHandler used by the current route function to be a NotTipParamHandler via the param_handler_plugin property of Pait.
After running the code and calling the curl command can know:
When parameters are missing, an error message that the parameter cannot be found will be returned.
➜~curl"http://127.0.0.1:8000/api/demo"{"code":-1,"msg":"error param:demo_value, Can not found demo_value value"}
When parameter verification fails, the parameter name with verification error will be returned.