Taming the exceptions, part II

In the previous, overview article I put together all the nice things a Python IDE shows me along my source code. They are mostly static, meaning that they don’t have any relation to actually running the code. But we write code to execute it, right?

Let’s have a look at this program:

And the result on the console:

Look at that! The stack-trace is 3 times the character count of the program itself. It’s a lot of semi-structured text that is difficult to parse for a human.

Besides, there is a context switch involved between editing the source code and executing and studying the console.

The solution would be to bring as much action as possible from the console back to the source code. Or at least some action. Could we do better in visualizing this error? How about the same error in a better form:

I spend a lot of time switching between a console and the editor, focusing and parsing the exceptions and getting back to the editor where I search for the right file and line number.

I think there is a low hanging fruit in a form of a simple IDE plugin which automatically parses console output and logs and visualizes the exceptions in the right way.

There would be a simple accompanying console command which would do do same as cat plus immediately forward the exception output to the IDE. That should integrate with most workflows nicely.

How would you want to see exceptions in your IDE? What is the prior work in this direction? How to design the UI for unit test results and failures?