Why do new programmers seem to ignore compiler error messages/runtime exception messages? [closed]

I think the real reason is that ordinary computer users, even if they should go on to become programmers, are conditioned to believe they can't do anything about errors. Think about it. What do non-programmer types do when they encounter a cryptic error message*? They might read it, but nine times out of ten they'll simply dismiss it and try again. Only if it consistently fails will they look it up.

Therefore, when beginning to learn how to program, people don't immediately realise that the error they're getting contains useful information on how to fix it; and yea, though compiler errors can be nigh unreadable even to the trained professional (I'm looking at you, C++ template metaprogramming), at least they provide a general starting point, and once you've seen the same error a couple of times, you'll always know what you've done to cause it.

*Honestly, though, most error messages look to Joe Average like "Error X2412: Unable to establish frobnicatory interplatforming dongledash: please verify bandersnatch settings or contact your system administrator."

I think if it is a true beginner there's a good chance they don't know there is an error message at all. They only know it doesn't run and that there is an error. For example in Visual studio they may not see that part of the screen.

Basically they don't know which part of the information they have available is useful to figure out what the problem is. If they did there would be a better chance they could fix it themselves and not ask about it in the first place.

I think that asking questions and troubleshooting is a skill that needs to be learned, and for professional developers, it's an important skill that simply isn't taught often enough.

Just as the code you write when you first start in this profession is going to be horrible compared to the code you write today, the questions you ask are going to be terrible compared to the way you ask them today.

When you start out, it's easy to be overwhelmed by all of the information that you are learning and when things aren't going to plan, it's difficult to know what information is relevant and what isn't. This is a big part of the reason why beginners can't solve the problem for themselves in the first place!

This applies more on IRC than online websites such as Stack Overflow, which is much more rare.

I think the reasoning behind it is that people feel better if they know that a person in particular is interested in their problem and is willing to help them. So they start by saying that they have a problem, but they don't go into details until someone asks them, because they are afraid that otherwise they won't get an answer anyways.

Sometimes (not in the case of compiler errors) this behavior actually makes sense. If I have a big complicated problem I'll make sure there is someone listening first before writing a long explanation that no one will read.

Because compiler errors/exceptions require you to know what you're doing wrong to fix it. They're for programmers who overlook stuff, not for people who don't understand them.

They're also not always the most obvious. An error like "unexpected if" isn't that intuitive. "But that if should be there" is the response of a newbie. A more experienced programmer knows that that means he's forgotten the semicolon on the preceeding line.

I don't think it's only newbies. I have co-workers with years of experience who seem to only look at the line number when they get a compiler error, then try to figure out the rest themselves (often by trying voodoo like "let's add parenthesis" or "let's break this up into two statements").

My suspiscion is that this comes from not really having a deep understanding of the rules of the language, so that the generally dense description of the error doesn't have much meaning. expression must be a modifiable lvalue seems like pretty useless information if you really don't know what an lvalue is.

What is it about error messages that makes people initially assume that they are useless and not worth paying any attention to?

Well, for me, it was a youth filled with crashing Windows 95 software with completely impenetrable error messages that usually ended with about 150 lines of hexadecimals.

I relive the same experience every time I get a nice cryptic Java stack trace which will contain 40 lines of compiler crap and Hibernate errors, and hidden very well amongst them is the actual reference to where in my app the error is.

The reason people ignore error messages and stack traces is often the error messages and stack traces are disproportionately complicated compared to the complexity of the problem. There is no reason to flush 150 lines of crap through my screen when I miss a semi-colon.

I'm teaching some courses on Linux for Junior Sysadmins, and Programming with PHP and Mysql. Majority of students on PHP know there's an error because they see the ugly message on screen. But they seem unable to read it. Usually I go to their screen when they tell me something isn't working, I read the error on the screen, tell them to read it, emphasizing the file and line noted on the error and tell them to look there. They correct the error, but when another error appears, the same procedure applies... sigh...

For the Linux course, sometimes they don't even notice the error. They enter some command, some lines appear on screen, and continue with the next command. When some commands later they at last notice something isn't working and raise their hands, I come up, scroll up the console and point to a command that exited with an error due to bad parameters or whatever. Their face: surprise. So the easy part for my linux students was to make them notice when an error occurs, using some modification of the bash prompt to make it different when an error appears, like this one. Now, get them to read the error message once they see it, that's a different battle (the same as with the PHP students)...

I believe that they are just not used to think about error codes, and by the time they reach the place where they should give them, they already feel like they fully explained the problem, and are therefore even less likely to stop and think about whether they should give additional information.

Asking a question involves a few stages, and they are most logically arranged in this order:

1. you need to describe what you were doing
2. you need to describe how you were doing that
3. you need to describe what happened when it failed (or how it failed)
4. you need to give the post mortem report

The post mortem report is where the error message will be, and it is at the very end. By the time newbies reach this point they are at the end of the mental challenge of explaining their problem and are more likely to miss something (for a newbie, there's an information overload problem). Further, at this point they already feel like they described all aspects of the problem, and they have past habits that prevent them from remembering about the error codes: after all, other fields of life have no error codes, so they are not used to think about them.

It may also be that even if they do remember about the error codes, they seem too cryptic to be of actual use. Just what is error 034982? Does this really mean anything to anybody? And does it really add something to that detailed description of what I was doing, how I was doing it, and how it failed? Surly this information stands for itself.

Because for most languages, most compiler/runtime messages don't make any sense. (C++ and Java especially, I am looking at you!) Getting the errors right tends to be rather low on a language designer's list of priorities. Getting things that work right to work right is usually a bigger priority, and a lot of time they don't bother with polishing the little details.

That's one of the reasons why I enjoy working in Delphi. The entire language is full of attention to the little details, including the errors. Compiler messages make sense. Runtime error messages make sense. Stack traces make sense. It's one of the things that makes it, by far, the easiest language to debug that I've ever worked with.