I think we’ve all seen this. Beginners ask questions on Stack Overflow that follow the basic outline...

I’m trying to do (very vague description of the goal) but it doesn’t work/I get an error/exception. Please help!

Isn’t it bizarre that so many of them seem to consider it unnecessary to paste the error message?

I wonder what the psychology of this is. What is it about error messages that makes people initially assume that they are useless and not worth paying any attention to?

The answer I’m looking for is not “they don’t understand the error message”. That doesn’t explain why they wouldn’t consider telling anyone else who might understand it.


10 Answers 10


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."

  • 6
    Do you mind if I use that error message in my software?
    – I.devries
    Commented Nov 6, 2014 at 15:54

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.

  • That’s a fair idea, but does that really explain the high volume of such questions?
    – Timwi
    Commented Sep 7, 2010 at 16:38
  • @Timwi: Maybe it explains the relatively slightly less volume of questions with proper error information. The absolute volume of bad questions is relative to the community size. Commented Sep 7, 2010 at 16:40

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.

  • Gods, I wish it still applied more to IRC than SO... Commented Jan 23, 2019 at 19:03

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.

  • Sure - but there's a difference between thinking something is cryptic and thinking it's useless. Commented Apr 26, 2011 at 18:16
  • 1
    @David: what use is a cryptic error message?...not much.
    – user3792
    Commented Jun 14, 2011 at 19:05
  • 1
    @Irontool: Quote it when asking on SO. Cut and paste it into a web search. Even if you don't understand it, it can act as a magic cookie. Commented Jun 14, 2011 at 19:37

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.

  • In my experience just looking at the code works well for syntax errors, since there the compiler message is often about a failure that's indirectly caused by the original error. For semantic errors, as in your example, the error message is usually essential. Commented Nov 6, 2014 at 14:48

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.

  • 2
    Hidden very well? Just scan for your package name. Commented Sep 21, 2010 at 9:56

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.

  • What environment/compiler/framework are you using that has purely numerical error codes? o.O
    – Timwi
    Commented Sep 8, 2010 at 11:47
  • I'm not using one such IDE. The error message itself may be deemed just as cryptic (unhelpful), or may sound like a rephrasing of the above description (doesn't add information). Commented Sep 8, 2010 at 19:15

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.