Search CompSci.ca
Subscribe
Programming
Compiler compliant, or figuring out error messages in code
“Informative, yet strangely mocking”. That is how compiler errors often appear to be. Sometimes they are straight forward, though often not as much…
Debugging software is an art of its own, without which it could be quite frustrating to explore the field of computer programming. The unchartered areas of computer code often come with ambiguous errors and bugs, and it seems that many students try to stay away from the unknown. There’s this fear of being told, by a computer, that you are wrong — though that may stem from the general tendency of schools to suppress creativity.
And that’s a closed loop — fear of errors discourage trying new things; isolation from errors limits experience of understanding bugs; limited experience spawns fear of dealing with errors. It’s a tough loop to break out of, especially if the educational system re-enforces the idea of not making mistakes. Though mistakes are there to learn from, and we must break out of this loop. Otherwise we give up creativity. We give up ability to deal with errors. We give up the sense of exploration and ability to understand and push a system to its limits. This is too much to pass up on.
There are many way of dealing with bugs and errors, and most come down to just one thing, understand exactly what you are doing. This is where the Computer Science part kicks in — set up an experiment that isolates the faulty code. This is kind of like deleting faulty code, but in reverse. Figure out what part of the code causes a problem. Figure out the problem. Really figure out the problem. It’s a learning process, and over time it’s easy to get a feel for what causes cryptic error messages, without the need to jump through the hoops to find that code. Though it takes practice.
I am not suggesting to break your own code on purpose (that’s just not the same), but don’t be afraid to have your code broken. It’s best to get in this habit early, as programming comes with a lot of errorous code: accidental mistakes and typos, having to deal with someone else’s code, or simply pesky University exam questions.
Read more
Discussion
Post a comment
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
Haha, Its worse trying to fix someone else’s bad code and having to sift through lines and lines to just solve a simple problem. Joys of xkcd comics, relive the brain on exploding from horrible code.
Reply to comment
Those crazy compiler errors really drive people crazy, don’t they? Fortunately, I don’t get them often because the code I write isn’t too advanced, and an error will be something like “cuot undeclared: first use this function” or something because of a typo I made. I usually I don’t try too many new things though because I’m not sure how to use them, or only a small bit on how, so I don’t get crazy messages. Maybe I should expand and start trying some new things in the language I am using.
Reply to comment
Back in the late 80s or early 90s there was a compiler (I believe it was called Clarion) that promoted a smarter compiler. The thinking was, if you got a compiler error that reported, “Error: Missing period,” clearly the compiler knew what the error was, and therefore could fix it — and should. In fact, this remains the case. Many code errors could be automatically repaired by the compiler if it were designed to do so. I think the notion of a self-correcting code is a frightening one to compiler developers, and therefore the notion hasn’t advanced.
Reply to comment
I am frightened of “self-correcting code” for a number of reasons. As a developer I would simply not want the system to start making assumptions about what I’m doing, as that will certainly end badly. From the educational standpoint, this would also encourage lax standards and breed programmers who would simply rely on the existing system.
Though from the practical standpoint, this is only feasible for the trivial mistakes with syntactic sugar — that is, if a compiler can figure exactly where the missing period must be placed, then we don’t really need that period at all.
Reply to comment
It can become extremely frustrating. In C++, I stand no chance because sometimes errors occur in headers I don’t even know about and it takes me a while to find that missing bracket in a completely different header. Even in Java, when I teach younger students who try really weird things such as if (expression) else (expression) instead of elseif, the compiler simply fails. Sometimes I get “construct” errors and it really amazes me how hard it is to find a typo in someone else code because you can’t imagine making the same mistake.
Reply to comment
Students will indeed try weird things, and what’s more is that such “weird” code will make absolute sense to them. That is why it is so important for them to learn to understand just what the compiler is trying to tell them.
Perhaps this is a yet another argument in favour of teaching with interpreted languages and interactive consoles. Syntactical errors are limited to a block of code, often just a single line. It could be a pain when two bugs in compiled code compound to an extraordinary bizarre situation.
Reply to comment
ahh…debugging…i used to love those harcore “debugging” sessions using softice
I used to adore softice. Too bad that numega had to kill such an excellent pieced of debugger.
Now, i am trying to cope up with windbg.
Reply to comment
Debugging your own code is insane when you have thousands of lines
Reply to comment