Improve error handling

[densnow]

Since time_it(), time_cases(), and time_functions() are higher-order functions, the source of any errors can be obscured.

To make it easier for the user to trace errors, we can catch exceptions and print additional information about the state of any functions involved in the error.

It might be best to catch exceptions in time_it() like the following

except Exception as e:
    print(f"Error occurred in time_it with function {function.__name__} and args {args}:\n {e}")

and then in time_cases() like:

except Exception as e:
    print(f"An error occurred in test case {cases[index].__name__} with size {size}:\n {e}")

And something similar in time_functions(). The exact details might need to change, but the idea is to pass on specific information about the state of the arguments that could be useful.

[mwermelinger]

Good idea. Could you please liaise with Steve about the errors he had and then work on this?

[mwermelinger]

Additionally, there should be a message if the %linter on command can't run the corresponding linter.

[densnow]

Looking at the ruff docs regarding exit codes it returns:

• 0 if no violations were found, or if all present violations were fixed automatically.
• 1 if violations were found.
• 2 if Ruff terminates abnormally due to invalid configuration, invalid CLI options, or an internal error.

This explains why we cannot just use the check=True option in subprocess.run in %ruff. If we want to distinguish between violations and abnormal termination we have to check the returncode attribute of the result from subprocess.run()

[mwermelinger]

To summarise so far:

• in DeepNote it's easy to not see the collapsed stack trace and miss any errors from the time functions
• linter output parsers ignore all besides violation messages and thus miss any other errors, e.g. configuration errors.

For the latter, would be good to catch the subprocess exit code and handle it appropriately.

[mwermelinger]

• [x] add to Deepnote docs how to expand stack trace

The linter errors are dealt as part of #29.