GSoC 20: Week 6

Hello everyone!

It's Niraj again. Today, I will be sharing my code contribution of the sixth week of the GSoC.

Background

Currently, we support five different logging level for output:

1. debug - Used when debugging to get additional info
2. info - Displays normal progress info (default)
3. warning - Only warning or error will be shown
4. error - Only error will be shown
5. critical (quiet) - No output only exit code will be returned

Default logging level is info but user can change it with -l option of
cve-bin-tool.

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.

What did I do this week?

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:

1. TruncTrace - displays truncated traceback (default)
2. FullTrace - displays full traceback (when logging level is debug and it can be set via -l debug option)
3. NoTrace - displays no traceback (when logging level is critical and it can be set via -q or -l critical flags)
4. 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.

What am I doing this week?

I am going to improve InputEngine and fix several open issues. See you next week.