Debugging Dart in Webstorm

Beyond print statements

One could argue that there are just 3 things you need to debug any dart code:

• a lot of print statements
• coffee
• patience

However, this tutorial will be about how to debug dart without using print statements (for logging to the console). I’m not trying to say that print is bad or anything, but Webstorm has a couple of nice debugging features which I think could save you time and make you more productive.

Last week, I’ve been working on a dart:io app, and I set myself the goal to debug this app without using any print statements at all. This forced me to really learn the debugging features of webstorm, and I would like to share what I learned.

What the app does, is reading a custom element defined in polymer 1.0 javascript, and then generating a dart class for this file, so that the custom element can easily be used in dart code. The main file of the app looks like this:

Old school print statements

So let’s assume we want to debug this app, maybe there is something strange going on and we want to quickly see what the parsed output of some javascript file looks like. The old school (and foolproof) way would be to print the output to the console.

This prints the output of 23 files to the console, and as you can see it is kind of a chaotic mess, we could however make our print statement a bit more specific:

We may want to make it even more specific. Maybe we are only interested in the output of one specific line, or whatever. But I think there is one clear thing that speaks against using print statements for debugging. We are now writing code, that doesn’t belong to our final app, but we are just writing it to debug and delete it afterwards.

In html files, we try to separate structure from style, and in a dart app we often try to separate code that belongs to the view from code that belongs to the model. In a similar way, you could argue that that it is desirable to separate debugging code from the real code.

Adding Breakpoints

One way to prevent polluting our app with print statements is using break points. Just click on a line number in the left bar, to add a breakpoint.

Note that you have to press the debugging spider visible in the top right of the screen instead of the regular run button, otherwise breakpoints won’t do anything.

Adding this breakpoint will literally act the same as adding our last print statement. As we have the suspend option disabled, we will only log the expression to the console.

Although we successfully separated the debugging from the code now, this doesn’t yet really saves us time. There are however a couple of neat tricks we can do if we enable the suspend option.

Show the value of the selected code

Make sure this option is enabled.

If we enable the suspend option, the breakpoint will really break the execution of the code at that specific point, and when the execution is freezed, Webstorm allows us to show the value of an expression, when we select it.

Select the expression (or double click it) and a popup will show the evaluated value.

Now in this case, the string representation of the parser object doesn’t give much valuable information. However, real magic happens if we press the + button on the left (or ⌘F1/ctrl-F1).

For who is wondering what those duplicate null values are, I think this is a bug in webstorm, see this issue.

Now we can zoom in at the exact information we were looking for:

That looks a lot more readable than printing it to the console!

So this not only allows us to separate any debugging logic from our actual code. This could also save us quite some time: finding out what an expression evaluates to, is just a couple of mouse click away.

Managing break points

Now, if you are going to play around with breakpoints, you may end up with quite a lot of them. Often you only want to enable 1 or 2 breakpoints in problematic areas, and disable all the rest. By pressing ⇧⌘F8 (or click the view breakpoints icon in the debugging panel), a window will popup that allows to easily manage all breakpoints:

So now we have successfully separated our debugging logic from the actual code !

I’m Kasper Peulen, if you found this tutorial useful, let me know, I may make a follow up one. And don’t forget to, code with passion !