It's Niraj again. Today, I will be sharing my code contribution of the sixth week of the GSoC.
Currently, we support five different logging level for output:
- debug - Used when debugging to get additional info
- info - Displays normal progress info (default)
- warning - Only warning or error will be shown
- error - Only error will be shown
- critical (quiet) - No output only exit code will be returned
Default logging level is info but user can change it with
-l option of
We want to have custom exit codes for every exceptions so that user with critical mode set on can know why program crashed. This mode is mainly used by automated scripts in CI/CD pipeline to reduce output dump.
Initially I added basic support for custom exit codes in my
InputEngine PR and my mentor liked it and wanted to have this support for every modules. So, I have got an idea to create a custom error_handler module with rich set of features.
I have created error_handler module which provides
ErrorHandler context manager. It can set custom exit code and displays colorful traceback according to the mode. It supports four different modes for error handling:
- TruncTrace - displays truncated traceback (default)
FullTrace - displays full traceback (when logging level is debug and it can be set via
NoTrace - displays no traceback (when logging level is critical and it can be set via
- Ignore - Ignore any raised Exception (Only used internally.)
I have moved all custom exceptions in error_handler module so that it would be easy for the new contributors to assign unique exit code. I have also changed excepthook to display colorized output traceback. I have also changed unittest for cli and input_engine to incorporate changes in exception handling. If one raises error without context manager he will get full traceback regardless of mode he set. So, always use
ErrorHandler context manager to raise exception or around the code that can raise exception.
If you want to see detailed implementation see my Error Handling Improvement PR
This week my mentor has also pointed out several issues in my InputEngine PR and I fixed those too. I have fixed Issue: Use patterns in VERSION_PATTERNS as valid CONTAINS_PATTERNS by default and for that I have changed checker metaclass to include
VERSION_PATTERNS by default as valid
CONTAINS_PATTERNS. I also changed mapping test data of all checkers and removed redundant
CONTAINS_PATTERNS. I have also fixed Escape sequence issue.
I am going to improve InputEngine and fix several open issues. See you next week.