![\"\"](\"/assets/images/debug1.png\")
Debugging is the process find removing a fault in your code\n(the etymology goes further back\nthan the moth story, I learned today). Being able to debug is an essential programming skill,\nand being able to program flawlessly is not enough; the bug can be outside your own code.\n(… there is much that can be written up about module interactions, APIs, documentation, etc,\nthat lead to malfunctioning code …)
\n\nWhile there are full debugging tools, achieving the task of finding where the bug is can\noften be reached with simpler means:
\n\nKeeping track of error messages is first starting point. This skill is almost an art:\nit requires having seen enough for them to understand how to interpret them. I guess\nerror messages are the worst developed aspects of programming language, and I do not\nfrequently see programming language tutorial that discuss error messages. The field can\ncertainly improve here.
\n\nHowever, at least error messages in general give an indication where the problem occurs.\nOften by a line number, though this number is not always accurate. Underlying causes of\nthat are the problem that if there is a problem in the code, it is not always clear what\nthe problem is. For example, if there is a closing (or opening) bracket missing somewhere,\nhow can the compiler\ndecide what the author of the code meant? Web browsers like Firefox/Iceweasel and\nChrome (Ctrl-Shift-C) have a console that displays compiler errors and warnings:
\n\n
Another issue is that error messages can be cryptic and misleading. For example, the\nabove error message “TypeError: searcher.bytag is not a function example1.html:73”\nis confusing for a starting programmer. Surely, the source code calls searcher.bytag()\nwhich definately is a function. So, why does the compiler say it is not?? The bug here,\nof course, is that the function called in the source code is not found: it should be\nbyTag().
But this bug at least can be detected during interpretation and executing of the code.\nThat is, it is clear to the compiler that it doesn’t know how to handle the code.\nAnother common problem is the situation where the code looks fine (to the compiler),\nbut the data it handles makes the code break down. For example, an variable doesn’t\nhave the expected value, leading to errors (e.g. null pointer-style). Therefore,\nunderstanding the variable values at a particular point in your code can be of\ngreat use.
\n\nA simple way to inspect the content of a variable is to use this console visible in\nthe above screenshot. Many programming languages have their custom call to send output\nthere. Java has the System.out.println() and JavaScript has console.log():
![\"\"](\"/assets/images/debug2.png\")
Thus, if you have some complex bit of code with multiple for-loops, if-else statements,\netc, this can be used to see if some part of your code that you expect to be called\nreally is:
\n\nconsole.log(\"He, I'm here!\");\nThis can be very useful when using asynchronous web service calls! Similarly, see\nwhat the value of some variable is:
\n\nvar label = jsonResponse.items[i].prefLabel;\nconsole.log(\"label: \" + label);\nAlso, because JavaScript is not a strongly typed programming\nI frequently find myself inspecting the data type\nof a variable:
\n\nvar label = jsonResponse.items[i].prefLabel;\n\nconsole.log(\"typeof label: \" + typeof(label));\nThese tools are very useful to find the location of a bug. And this matters. Yesterday,\nI was trying to use the histogram code in example6.html\nto visualize a set of values with negative numbers (zeta potentials\nof nanomaterials, to be precise) and I was debugging the issue, trying to find where\nmy code when wrong. I used the above approaches, and the array of values looked in\norder, but different from the original example. But still the histogram was not\nshowing up. Well, after hours, and having asked someone else to look at the code\ntoo, and having ruled out many alternatives, she pointed out that the problem was\nnot in the JavaScript part of the code, but in the HTML: I was mixing up how\ndefault JavaScript and the d3.js library add SVG content to the HTML data model.\nThat is, I was using <div id=\"chart\">, which works with document.getElementById(\"chart\").innerHTML,\nbut needed to use <div class=\"chart\"> with the d3.select(\".chart\").innerHTML\ncode I was using later.
OK, that bug was on my account. However, it still was not working: I did see a\nhistogram, but it didn’t look good. Again debugging, and after again much too long,\nI found out that this was a bug in the d3.js code that makes it impossible to use\ntheir histogram example code for negative values. Again, once I knew where the bug\nwas, I could Google and quickly found\nthe solution for it on StackOverflow.
\n\nSo, the workflow of debugging at a top level, looks like:
\n\nHappy debugging!
", "summary": "Debugging is the process find removing a fault in your code (the etymology goes further back than the moth story, I learned today). Being able to debug is an essential programming skill, and being able to program flawlessly is not enough; the bug can be outside your own code. (… there is much that can be written up about module interactions, APIs, documentation, etc, that lead to malfunctioning code …)", "image": "https://chem-bla-ics.linkedchemistry.info/assets/images/debug2.png", "date_published": "2014-11-16T00:00:00+00:00", "date_modified": "2025-02-15T00:00:00+00:00", "tags": ["pra3006"], "authors": [ { "name": "Egon Willighagen", "url": "https://orcid.org/0000-0001-7542-0286" } ] } ] }