Hidden assumptions cause more frustration than the bugs themselves because they send you down the wrong trail. A perfect example is the “Invalid column name” error that many people get from Hibernate running over Oracle. Basically, you execute some Hibernate, get an invalid column name error, but when you try to run the generated SQL, everything works. People become completely confused by this. How can the SQL run fine standalone, but have an invalid column problem when running through Hibernate? What the heck is wrong with Hibernate?
Nothing is wrong with Hibernate. You're confused because of the hidden assumption that you don't realize you have. You're assuming if you get a SQL error there must be something wrong with the SQL statement itself. But since the SQL runs fine standalone, you know the SQL statement doesn't have a problem with it. You're assuming SQL is just a statement, but more goes on after the statement is executed. After a SQL statement is executed, the data from that statement is retrieved using column names. One of those column names was either not added to the SQL statement or is somehow incorrectly quoted, which is why you're getting an “Invalid column name” error.
If you've ever faced this problem, you know how confusing it is when you first get the error message, but how it suddenly makes sense once you know what to look for. The error message would be more helpful if it was something along the lines of “Invalid column name mapping” because you would be more likely to look in the right place. And all that's been added to the error message is a single word. This brings up an important point about how error messages need to written. An error message about the actual SQL statement can be terser, because that's the first thing that people look at when something goes wrong. When an error happens in any other part of a SQL call there needs to be more information, because programmers don't think of those parts of a SQL call.
The typical answer to these kinds of confusion is to complain about the lousy error messages, but something has to be said about the programmer reading them as well. If you're in a situation where things aren't making sense, you need to back up and look at what you're assuming the error is. You confusion will usually go away once you're able to consider other places the error could be. However lousy the error messages might be, you need to keep this in mind, because sometimes you're the person who wrote the crappy error message.
