• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

run time error&compile error?

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi:
We should like to ask that how to compare with
run time error and compile error? Thanks!
 
Ranch Hand
Posts: 1258
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A runtime error is an exception thrown during the execution of a program. It usually denotes some unanticipated event. A compile-time error occurs when the compiler cannot compile your java source code into byte-code due to some incongruity between your source code and the Java language specification (e.g. syntax errors).
As you can tell, you can only experience a runtime error if your program is runnable, and therefore not have any compile-time errors.
 
Cowgirl and Author
Posts: 1589
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Howdy -- I just wanted to add a little more. Nathaniel gave you the good description of the differences, and here's another way to think of it...
If the compiler can tell FOR SURE that something will DEFINITELY not work, you'll most likely get a compiler error. If the compiler cannot be sure, OR if the error cannot really happen until runtime, then it's a runtime exception.
For example, if you say in your code:
int x = "foo";
This violates the Java language rules because Java is strongly typed, and you can't stuff a String (which is an object) into a primitive int variable. So, compiler error.
Same with
Dog d = 27;
Dog is an object reference type. You can tell because it is NOT one of the defined primitive types. So, you cannot assign an int literal to an object reference type. Compiler error.
BUT... (and this one might be ahead of where you are at this point, but here's an example for the future...)
class Dog extends Animal { }
class Cat extends Animal { }
class Animal { }
Cat c = new Cat();
Animal a = c; // now we have an Animal reference referring (pointing) to a Cat object
Dog d = (Dog) a; // whoa! Will it compile? Will it run?
This compiles because the compiler says to itself
"Hmmm... a Dog is indeed an Animal. The variable 'a' is indeed of type Animal. Therefore, the THING (object) referenced by the 'a' variable might actually BE a Dog. It's possible that it IS a Dog, so I'll allow it to compile. But I sure hope it works at runtime." the compiler thinks, 'I sure hopt is isn't a CAT or this code will blow up at runtime..."
And in fact, the code DOES produce a runtime exception because of course, when it's running, the object at the other end of the 'a' reference really IS a Cat. Yikes, you can't have a Dog reference pointing to a Cat object. That just horrifies the JVM.
So that's an example of something the compiler cannot be certain of, so the compiler permits it because IT IS POSSIBLE. Even though it turns out to cause a runtime exception.
Now, you can say, "Surely the compiler can just look in the code and SEE that 'a' refers to a cat object. It's right there in the code!" But remember, that code that assigns a Cat to 'a' might be really far away from the line that tries to cast it to a Dog reference variable. The compiler isn't going to be able to wander back and see what's really in there. The compiler ONLY cares about type -- so it looks at the reference TYPE of 'a' and says, "Animal". Then it looks at the type for what you're trying to cast it to and says, "Dog". Then it looks at the class structure and says, "Dog extends Animal" and thus it knows now that an Animal reference could be pointing to a Dog object.
But here's something the compiler knows for SURE will NEVER work:
Cat c = new Cat();
Dog d = (Dog) c; // no way
The compiler can now TELL that 'c' is referring to a Cat (or perhaps a subclass of Cat, doesn't matter) and the compiler says, "There is NO way that whatever is at the other end of 'c' can be an object that can be referred to be a Dog reference. A Cat simply cannot be cast to a Dog.
Cats don't bark. Chances are, the Cat class doesn't have a bark() method, and remember, if somebody has a Dog reference, they are GOING to ask it to bark().
That's the cool part of Java's strong typing. The compiler stops you from asking a Cat to bark().
cheers,
Kathy
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic