TRI-AMDD/beep

Logging can be more comprehensive

Closed this issue · 0 comments

For small operations, including when files fail in a batch operation, very little relevant data is printed to console or can be shown.

For example, batch processing a bunch of runs where one fails, the only error that is returned is shown in the processed json output, which says "insufficient data". We can instead save the stack trace and return that in json.

Another example: A warning can be logged if determine_structuring_parameters does not find a diagnostic. If someone is expecting their files to have a diagnostic, and beep isn't structuring them correctly, this is useful information.

Additionally, we can set logging levels for smaller operations (showing things like what the structuring parameters are when they are determined) to DEBUG or INFO (not important). We can similarly set batch operation logging (whether a file was successful or failed) by setting their log level higher (WARNING or ERROR); these logging ops can be filtered easily by the logging module.

The end result would be logging that is both complete (high res) yet not overwhelming (can be filtered).