This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Dad! I didn't know you were learning java! (ok.... maybe this is a different Steven Bradley than my Dad... but its funny to see the name . -- I did give him a copy of Head First Java for Father's Day last year, you know. )
Hmmm...I'm having a hard time coming up with a good answer for you.
Personally, I think the best way to think about these things are that compiler errors are things that could never work. For example, a missing semicolon would lead to not being able to read some instruction(s). Or invoking a method that doesn't exist would never work, either.
A runtime exception, on the other hand, is what happens when something could work, but doesn't. For example, maybe you're doing a bit of division and it turns out that the variable you're divinding by is a 0. That would result in a run-time exception. Had that variable been something besides 0, this would have worked fine - therefore, it's not a compile-time exception.
So, maybe it's an over-simplification, but that's the best way I can think of looking at it. Compile-time errors are things that will never work while run-time exceptions are things that fail, but could have worked had the circumstances been different.
I look at compiler errors as code that is simply wrong from a syntax point of view. For instance, trying to use a Java keyword as a variable name or something to that effect is an obvious compile error. I think of Runtime exceptions as the result of syntaxtually correct code that is improperly designed or thought out, and only blows up once in awhile when it chokes on data. It sounds lame, but you need to put yourself in the compilers shoes, and think about what it knows at compile time and what it doesn't. For instance, if you try to declare an int and programatically assign 10.0d to it (a constant that the compiler knows about because it's hard-coded), the compiler knows that a double can't be converted to an int without an explicit cast and a compile error occurs. However, if you read 10.0d off of a file (or any other way that makes 10.0d not a constant value), that value is not known to the compiler at compile time and won't be known until runtime. This is a runtime error, because the compiler doesn't know what users are going to input or what data is going to be read in from a file, until runtime and this stuff actually happens.
Aside from that, there's no glaringly obvious way to tell the difference, it all boils down to being able to look at code and rule out syntax errors, then proceed to looking at all of the data that is known at compile time and not known at compile time, and making your decision based on knowledge and common sense.
Joined: Jun 09, 2004
Thank you for helping with such an abstract question - please let the sheriff know I am a different Bradley