Debugging your task

As important as building your task is making sure it works correctly. In other words, you need to find out what is wrong in your Survey when it doesn’t work quite like you expected. This guide will be a collection of different debugging strategies you can employ to check what went wrong while building the task. Please read on! <This guide is currently under construction>

 

Opening the debugging console

This is probably the most important step in debugging your task. The console will contain most information about tasks that aren’t working, by either showing an error if there’s a syntax error (often a simple typo) in the code, or by showing more complicated information regarding the current error.

Different browsers have different ways of opening this debug console, a good overview of which can be found here: http://webmasters.stackexchange.com/questions/8525/how-to-open-the-javascript-console-in-different-browsers. We will base this tutorial off of Chrome debug console, but there shouldn’t be many differences between browsers

Now that you’ve opened your console, it’s time to start looking at the possible errors that arise while working on your task.

1. General Syntax Error

A syntax error happens when a certain character (or combination of) is placed where it doesn’t belong. For example semi-colons (;) where commas (,) are expected, etc. Syntax errors stop the code from working at all, so they are quite pressing issues to fix. Luckily, the debug console allows you to easily fix these issues by showing an error and displaying a link to the line that’s at fault. Let’s look at this (faulty) code to initialise a Stimulus question:

In total there are 5 syntax errors present in this code, let’s use the console to find all of them. If you want to follow the steps we provide here, please copy-paste and the code above into one of the Stimulus question’s JavaScript boxes.

Note: We have based this off the QRTE Skeleton Task, which can be found here. However, the techniques explained in this tutorial are not strictly limited to it. Also, errors are generally evaluated on a ‘per question’ basis, so having an error in one of the question’s JavaScript will not stop other question’s JavaScript from running. This usually results in the question’s stimulus being omitted from the QRTEngine stimulus queue.

first error

For the first error, the console output should look something like this (in chrome). The link to the right brings you to the line that is at fault. In this case, the error is that there’s a comma rather than a dot after QRTE, but the reported syntax error doesn’t show up untill the line after that, where it suddenly runs into an unexpected semi-colon. So, although the console will do its best to send you in the right direction, it can only give you the line where the syntax error happens, and not where the actual mistake happened!

So, we change the comma into a dot and run the task again. The same line is at fault again, and the same syntax error is shown! Looking at the code we find that the parameter object was not correctly opened, so we have a missing right-curly-brace ‘{‘. Add that after the opening parenthesis, and the code will look like this:

A basic rule of thumb here is that certain characters ( {, ( , [,  and more) always need to be matched by their counterparts ( }, ), ] ) and other characters, such as ‘, ” and , need to be matched by themselves ', ", , so that there’s always an even amount of those characters in your code (excluding properly escaped characters).

Our next error should be fairly obvious, there is an unclosed String ‘TestItem, because the matching single quote ‘ has been mistakenly replaced by a double-quote “. The accompanying syntax error is not quite as obvious, namely:

Uncaught SyntaxError: Unexpected token ILLEGAL

This is because the unexpected token is not quite as obvious, as the string is never closed and runs through to the end of the html element. So, to fix the error, change the double quote ” into a single quote ‘.

Now that we have the general idea, I will leave it up to the reader to discover and fix the remaining syntax errors in the code!

2. Debugging more complex code (during runtime)

Having been able to get rid of every syntax errors in your code,  we now move to the more complex area of fixing runtime errors in your code. Runtime basically stands for ‘while the code is running’, and errors resulting during runtime (or while the code is running) are usually more difficult to fix, as the environment in which these errors arise is fleeting. Ie, without “special” tricks, you can’t really know the context from which the error rose. We’ll list a few these tricks that should allow you to handle most common runtime errors.

2.1 Using console error output

Warning: this is about to get technical!

One of the most important ways to debug your code is by using output in the console the get an idea of what was going on behind the screen. If the browser encounters an error while running the code, it will usually throw up a an error with a link to the line where the error happened, like when the browser runs into a syntax error.

Note: Like I mentioned before, all browsers have consoles that allow you to view some of the output that a website gives behind the screens. However, you can usually also run your own JavaScript code in the browser, this should allow you to more quickly test the concepts presented in the following part of the tutorial. Here is a good overview of how to do just that for each browser: http://masonaxcte.wikia.com/wiki/Run_JavaScript_in_Browser_Console

For example, simply adding something like this to your JavaScript

will cause an error to be thrown up. The issue here is that test, which is assumed to be a function, has not yet been defined before. Thus, cannot be called. If you intend test to actually be used in your code, then you know something went wrong when defining the test function.

The same thing happens when attempting to use use a property of an object that hasn’t been defined yet:

Hi, as a property, hasn’t been defined yet, so can’t be called as a function. There is no real bound to the complexity of these runtime errors, so one needs to have several tools to tackle these types of errors.

2.2 Inspecting your variables

First off, finding out where exactly the error happens can often be done using “debugger” statements. Adding the line  debugger; in your code will make the execution of the JavaScript pause and will allow you to inspect the current state of your browser. Try, for example, executing the following code:

This will pause the code after running the line  test = {}; , and when unpaused again the 3rd line will be ran. As mentioned before, we can run this code in our console. And it will pause, showing the following window:

The circled button will unpause the execution when pressed

pausedebugger

At this point in the execution, test.hi hasn’t been defined yet, and we can actually test that! If we enter test.hi() in the console during the pause, like so:

debuggerpauseerror

We get an error! However, after unpausing by clicking the button circled in red, test.hi will be defined and thus callable! Running test.hi() again will now give us:

debuggerpausecorrect

 

Giving us ‘hi’!

Using debugger, you can inspect everything you want on the fly while creating your task.

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">