MoldableExceptionsOnwardSlideshow

Moldable Exceptions

Hello. My name is Oscar Nierstrasz.

Today I'd like to tell you about Moldable Exceptions , which is to say, how you can adapt your debugging tools to your application domain, and make debugging a more pleasant experience.

The trouble with generic debuggers

The problem with generic debuggers is that they are all the same. They all show you more or less the same stack-oriented view of the execution context no matter what kind of error is raised.

In this example we assert that two strings are equal, and enter the debugger when they aren't. The example is not very complex, but the debugger does not really help us to figure out what is wrong.

Even if we dive into the code, we do not immediately see what is wrong.

- Evaluate the example. - Inspect the two subexpressions. - We do not immediately see what is wrong.

Custom debugger views

If we change the example slightly to use #assert:equals: instead of simply #assert:, then we know that the error is due to a failed comparison. With this extra knowledge, we can inform the debugger to provide a more informative domain-specific view.

The textual diff shows us exactly where the problem lies.

We can still access the generic debugger view, if we want.

- This time we see the detailed comparison. - Show also the generic view.

File System Errors

In this example we not only obtain a more informative view showing us what is wrong with our request, highlighting the missing directories in our path, as opposed to the terse message we get in the generic debugger view, but we are also offered corrective actions.

Too many URL redirects

This example raises an error when retrieving the content behind a URL if too many redirects occur.

In this case the generic view is the default one, rather than the detailed view of the redirects.

In both cases, however, there is a custom Retry action that lets us proceed and retry with a higher threshold of redirects.

- Show the views and retry.

Moldable development in a nutshell

Moldable development is a methodology that makes a system explainable by extending it with numerous custom tools that answer specific questions about the system and its underlying domain concepts.

Moldable development depends on the existence of moldable tools , IDE tools that have been opened up to accommodate and enable custom tools within well-defined contexts.

For the moldable debugger, this happens when a specific kind of exception is raised.

The Moldable Inspector

The Moldable Inspector is an example of a moldable tool.

Here we see a moldable object inspector on a live instance of a Ludo game.

The usual inspector view of objects is the Raw view which only shows the state of the object's instance variables. Instead we have molded the inspector to show us several custom views that explain various aspects of the game.

We can see the state of the Players, the individual Squares, and the history of the Moves.

We can furthermore dive into a particular move, and see further custom views that explain what happened. We can even step through the moves to obtain a kind of animation of the history of the game.

Each custom tool consists of a short method that informs the inspector, or another IDE tool of the extension.

- Show the Raw view - Show the views one by one - Dive into the moves - Step through the moves - Show the code of the Moves custom view

Specifying debugger views

We specifying debugger views in pretty much the same way as inspector views, only using a different pragma (or annotation).

In this code snippet we start with a live example of a partially played Ludo game, we programatically roll a 6, and attempt to move player B forward.

This raises a domain-specific assertion failure to which we have associated a custom view to explain the problem. In the Moves view we clearly see that it is the turn of Player C.

In fact, the view we use is a pre-existing inspector view, so there is essentially no additional cost to reuse it in this context.

Specifying actions

Custom actions are specified in a similar way, but with a different annotation..

This action actually has two different pragmas since it appears both in the custom view and the stack view.

It's just a dropdown menu that retries the action with the same debugger.

- Trigger the exception - Show the action code with two pragmas - Show the action appears in both debugger views

Debugging views

A nice use case is to catch common errors and offer repairs.

In this example we have an object with an optional view that should only appear if there is data to display. Unfortunately there is an error, and a broken view is shown instead. The problem is that instead of returning the view, it should return an empty view.

The moldable exception not only highlights the error with an explanation, but it even offers a simple refactoring to fix the error. If we apply the refactoring, execution continues and the correct inspecxtor view is returned.

- Inspect the first snippet. - Show the view code. - Inspect the second snippet. - Show the proposed refactoring and apply it.

Debugging specifications

(Skip if time is short.)

We can also configure customizations in various ways.

In the first example, if we inspect the debugging session, we can see that an Assertion Failure specification has been detected, and we can explore its properties. We see in gtExceptionDebuggerSpecification that it is enabled only when there are compatible types to compare.

If we inspect the code of the second exception, we see in the method gtExceptionDebuggerSpecification that availableAutomatically is set to false. This means the generic stack view will be shown by default.

The class GtMoldableExceptionSpecificDebuggerSpecification supports a number of such configurations.

- Trigger the first debugger - Inspect the debugging session and shows its properties - Inspect the AssertionFailure exception and shows its view is the same - Trigger the second debugger - Inspect the exception and go to the Meta view - Show the code for gtExceptionDebuggerSpecification - Open the super code bubble - Explore the class comment of GtMoldableExceptionSpecificDebuggerSpecification

Summary

... More examples for discussion.

... Some metrics for discussion.