Subscribe to andrewsw's Blog        RSS Feed
***** 1 Votes

Where is my error?

Icon 5 Comments
In order for someone to help you to solve your problem you have to help us to help you. First, post the relevant code wrapped in code-tags. Highlight the code and press the [ code ] button just above where you are typing. Press the Preview Post button until it is correct.

Post relevant code. That is, not a single line and NOT your entire code (unless this only amounts to a reasonably small number of lines - say 30 lines). Don't worry about not posting enough code: if more is needed you will be asked to provide it.

If you receive error messages, post them: don't try to summarize or paraphrase them. If the error messages are HUGE then you'll notice that there are many repeated lines in the middle; this repetition can largely be deleted - just type something like "Repeats..". In almost every circumstance it is the first few, or the last few, lines that are of most interest. Don't be upset at the number of error messages; often many of them will disappear after a single correction.

The error messages will contain line numbers. Tell us which lines these refer to in the code that you have posted as these will often be different to the lines of your original code.

Tell us what is happening. That is, what does your code do? What does it not do that it should be doing? Just saying "Doesn't work!" is not helpful and will not encourage people to try and help you.

Tell us what computer (operating system and version) you are using, what version of the programming language, what editor. Tell us how you run your program; that is, from your editor or the command-line. What is the text of the command-line that you use.

Finding your own errors

  • Use a good editor or IDE. It will underline or otherwise indicate errors. If you point at the underlined text it may pop-up with suggestions to correct the error.
  • Use Google (or other search engine). Search a line - usually the first - from your error message(s). You might precede it with the language name: 'Java "your error message text"'. Study the results. You need to become familiar with error messages, their meaning and solution.
  • Use lots of message-boxes, alerts, etc., to confirm values as your code runs.
  • Learn to use the debugging tools of your chosen langauge or editor. You will be able to step-through your code one line at a time, to keep an eye on the values of all your variables, introduce breakpoints, etc., etc.. If Javascript is your language, you need to learn to use your browser's console.


Typical errors

  • Have you declared all your variables?
  • Are they in scope? Are they the right type (integer, string. etc.)?
  • Is your CASinGcORrect (casing correct)?
  • Check your spelling. Erm, check your spelling again!
  • Every opening bracket must have a closing bracket.
  • Do your functions/methods return a value? Is it the correct-type? Is the return value stored somewhere by the calling-code?
  • Have you correctly imported any required libraries or modules?


Finding errors - the process

You must maintain an open mind. That is, you cannot discount anything! All you can do is to consider certain possibilities as "unlikely" or "highly unlikely".

The process, in very general terms, works like this:

  • Initially you have an idea where the error lies, to within a line or a few lines. Concentrate on this area and examine the code in detail. Introduce messages or printouts of significant variables and values. Use debugging tools to step-through the code.
  • If you don't discover the error then you need to broaden the scope. Work outwards (or backwards?) to the lines before where you thought the error occurs, or to the function that called this function. Again, print-out significant (or all!) values or variables.
  • Broaden the scope again. Work outwards (again) to other functions that you may have assumed are working correctly.
  • Then you need to narrow the scope. Isolate sections of code that you can test; test until you are convinced that they work as expected. Then move on to other sections.
  • Take a break. Walk away from the code, have a cup of tea! It is frequently surprising how often this can lead to inspiration; or, at least, to a different perspective on the problem.
  • If possible, ask someone else to help you. Often you will find that simply describing, or attempting to describe, the problem to someone else can lead to a solution or insight.
  • Resist the temptation to re-write your code. The original error may still exist and you may introduce other errors, which will make your task harder. However, this advice does not hold if your code is very messy. If you know that you can re-write it in a more effective (efficient or legible) way then go ahead. If the code was a mess in the first place, then simply re-writing it may make your problem go away.


You can, however, edit the code to an extent. That is, to introduce messages or print-outs of variables, or to split complicated lines into simpler statements. This will make the code easier to debug (and to maintain in the longer term).

Concluding Words

Debugging (fixing!) code is both an art and a science. It takes patience, determination, ingenuity, often.. inspiration! And patience (again). It can, and often is, frustrating. But it is also rewarding and never a waste of time - every time you find a solution you approach nearer to prefection! Well, more realistically, the more experience you have of debugging the quicker you will find the next solution.

5 Comments On This Entry

Page 1 of 1

laytonsdad Icon

26 May 2013 - 01:33 PM
This is excellent, I feel like it should be in everyone's signature or pinned to the top of most sections. Great job, you nailed it.
0

andrewsw Icon

26 May 2013 - 03:00 PM

laytonsdad, on 26 May 2013 - 08:33 PM, said:

This is excellent, I feel like it should be in everyone's signature or pinned to the top of most sections. Great job, you nailed it.

Thank you very much for your comment and support ;).

Regards, Andy.
0

C.Andrews Icon

28 May 2013 - 11:44 AM
This is great advice; may I suggest mentioning Option Strict as well?
0

andrewsw Icon

28 May 2013 - 02:04 PM

C.Andrews, on 28 May 2013 - 06:44 PM, said:

This is great advice; may I suggest mentioning Option Strict as well?

Hello, and thank you.

There are obviously many things that were omitted. I'm a strong advocate of Option Strict On in VB.NET and am happy to emphasise it here. It is specific to a particular language though, and I was trying to keep my post language-neutral. (I do mention Javascript though, because the Console is a distinctive debugging feature.)

I perhaps might have mentioned naming conventions and indentation style as well, but this drifts slightly too far from my topic heading (I believe).

Thank you for the suggestion. I might consider it for another blog-post ;). Regards, Andy.
0

synlight Icon

05 September 2013 - 11:30 AM
Excellent post!!! I wish I had read this my first year in college when I thought I would never learn how to debug. My most common failure back then was forgetting == in decisions.
0
Page 1 of 1

Trackbacks for this entry [ Trackback URL ]

There are no Trackbacks for this entry

December 2014

S M T W T F S
 123456
78910111213
1415161718 19 20
21222324252627
28293031   

Tags

    Recent Entries

    Recent Comments

    Search My Blog

    3 user(s) viewing

    3 Guests
    0 member(s)
    0 anonymous member(s)

    Categories