I reviewed the Sun requirements for java exceptions and came up with my notes for study. Please look at them and let me know what I got wrong and what I left out. Please let me know if some things that are not clear enough. Others can answer your questions too. There are 10 exceptions in my notes at the end which I have not defined yet, but I will.
THE REQUIREMENTS FROM SUN WEBSITE
Develop code that makes use of exceptions and exception handling clauses (try, catch, finally), and declares methods and overriding methods that throw exceptions.
Recognize the effect of an exception arising at a specified point in a code fragment. Note that the exception may be a runtime exception, a checked exception, or an error.
Recognize situations that will result in any of the following being thrown:
I. Exception Hierarchy: all exception classes inherit from Throwable. Error and Exception descend from Throwable and from Exception the classes Runtime and IOException descend. Error exceptions are internal runtime system errors and beyond a programmers scope. They should not be thrown. Runtime exceptions represent coding errors that should be corrected within the code. It is not good programming practice to catch these. IOExceptions that may occur in a method should normally be caught and handled within the method. These are called checked exceptions.
Runtime exceptions: bad cast, array access out of bounds, null pointer access ... IOExceptions: file not found, reading past EOF, open malformed URL �
Checked exceptions require you to provide code to handle them. The compiler checks to see if you handle checked exceptions. Either catch or declare (throw) them.
Code goes in try block. Handler code goes in catch block. Always code into finally block.
when to declare: 1. your method may throw a checked exception 2. you call a method that says it throws exception. 2) you throw a checked exception but do not handle it.
V. Exception Processing.
When an exception is thrown, the runtime system checks for a matching catch block. The catch block is executed and then the finally block is executed. Execution then continues after the end of the try block.
If no matching catch block is found the finally block is executed and then control passes back to the calling method which checks for a matching catch block.
If no try block is specified then control passes back to the calling method which searches for a catch block.
When over riding a method you cannot throw new or more general exceptions than in overridden method.
Useful methods: e.getMessage(); e.getClass.getName(); e. initCause(); e. printStackTrace();
ArrayIndexOutOfBoundsException: Runtime Exception: Thrown to indicate that an array has been accessed with an illegal index. The index is either negative or greater than or equal to the size of the array.
ClassCastException: Runtime Exception: Thrown to indicate that the code has attempted to cast an object to a subclass of which it is not an instance.
IllegalArgumentException: Runtime Exception: Thrown to indicate that a method has been passed an illegal or inappropriate argument.
IllegalStateException: Runtime Exception: Signals that a method has been invoked at an illegal or inappropriate time. In other words, the Java environment or Java application is not in an appropriate state for the requested operation. NullPointerException: Runtime Exception: Thrown when an application attempts to use null in a case where an object is required.
NumberFormatException: Runtime Exception: Thrown to indicate that the application has attempted to convert a string to one of the numeric types, but that the string does not have the appropriate format.
AssertionError: Error : Thrown to indicate that an assertion has failed.
ExceptionInInitializerError: Error: Signals that an unexpected exception has occurred in a static initializer. An ExceptionInInitializerError is thrown to indicate that an exception occurred during evaluation of a static initializer or the initializer for a static variable.
StackOverflowError: Error: Thrown when a stack overflow occurs because an application recurses too deeply.
NoClassDefFoundError: Error: Thrown if the Java Virtual Machine or a ClassLoader instance tries to load in the definition of a class (as part of a normal method call or as part of creating a new instance using the new expression) and no definition of the class could be found.
Here's an Exceptions question I just made up. It addresses a situation that's frequently asked about in these forums. (The answer is covered in the bullet points I'm posting below, so you might want to try answering the question before looking at the next post.)
What will be the result of attempting to compile and run the following code?
a) Will not compile because there is no catch block. b) Will not compile because the uncaught Exception is not declared. c) Compiles and prints "abc". d) Compiles and prints "OK here". e) Compiles and prints "abc OK here".
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer sscce.org
You might want to add the following to your notes:
Checked exceptions include java.lang.Exception and all its subclasses other than RuntimeExceptions. (I think this was unclear in your notes, which seems to suggest that all checked exceptions are derived from IOException.)
A try block requires either a catch block or finally block. For each try block, there can be multiple catch blocks, but no more than one finally block.
If there are multiple catch blocks, they should be ordered from most-specific to least-specific, since the first matching catch block will be used.
Constructors are not inherited, so (unlike methods) they can throw Exceptions that are not declared in base class constructors. However, since derived constructors call base constructors, the derived constructors must still declare any base Exceptions.
A return statement in the finally block will cause any caught exception to be "lost," since the method will return normally.
Originally posted by megha joshi: ...I will be very greatful if I could get such points from you all for topics Generics and regex, my weakest areas...Can I start a new thread for it? ...
Yes, to keep these threads manageable, please start new topics for these points. [ May 08, 2007: Message edited by: marc weber ]
Joined: Apr 25, 2007
I was confused about the checked exceptions and the ioexceptions. From the text I read it seemed that the only checked exceptions were ioexceptions which struck me as odd. I must look up the other classes to see whats there.
I notice the error class exceptions are called somethingsomethingerror and the runtime exceptions class are called somethingsomethingexception. This is a good clue to what I am dealing with.
Well off to check on these other classes of exceptions.
I will incorporate your comments and corrections into my notes. thanks.
I understand there is also a chaining of exceptions so that each exception will point to the previous exception so that if three exceptions are thrown then there is a chain we can look up to see what happened.
I knew about the most specific exceptions first.
I wonder if you get a compile error if you leave out the catch and finally or it just assumes you knew what you are doing. I'll give it a try.
Originally posted by Joe Wolfe: ...I was confused about the checked exceptions and the ioexceptions. From the text I read it seemed that the only checked exceptions were ioexceptions which struck me as odd. I must look up the other classes to see whats there.
I notice the error class exceptions are called somethingsomethingerror and the runtime exceptions class are called somethingsomethingexception. This is a good clue to what I am dealing with...
All Errors are unchecked. All Exceptions are checked unless they are RuntimeExceptions (that is, a RuntimeException or any of its subclasses). Class names usually allow you to distinguish Errors from Exceptions, but you can't rely on names to tell you whether an Exception is a RuntimeException or not.
Originally posted by Abdul Mohsin: ...can you explain this a bit more...
An Exception basically says, "There's a problem that prevents me from executing this code." So inside a method, this means, "I'm not going to be able to finish this method and return normally."
When an exception is thrown, the flow of execution is transferred to the try/catch/finally blocks. However, if the finally block includes a return statement, then the method will return normally and control will be passed to the point at which the method was called. So whatever was caught will basically be lost.
Note that this is probably a misuse of finally, because if an exception is thrown, do you really want your method to return in all cases? The finally statement is basically for cleanup that should be performed even if the method does not return normally.
See "What's finally for?" from Thinking in Java, and also the section beneath that, "Pitfall: the lost exception."
Joined: Apr 25, 2007
Code printed abc okay here.
so the return causes the exception to be lost.
also when I complied a try without either catch or finally I got a compile error.
There were over 80 classes under exception and not runtime. And many of these had subclasses too.
hi Marc, you wrote: Constructors are not inherited, so (unlike methods) they can throw Exceptions that are not declared in base class constructors. However, since derived constructors call base constructors, the derived constructors must still declare any base Exceptions.
Can you provide an example and explain. I am not so clear about this point.
Originally posted by debasmita pattnayak: ...Can you provide an example and explain...
First, consider a method. If a method is declared to throw an exception, then an overridding method can also throw that type of exception (or a subtype of that exception), but it cannot throw any other type of checked exception.
Constructors are a bit different. They are not inherited, so they cannot be overridden. Therefore, constructors in derived classes are free to throw any type of Exception, regardless of what might be declared for the superclass constructors.
However, when a constructor is called, a superclass constructor is always called (either explicitly or implicitly). So if a superclass constructor is declared to throw an exception, then calling a derived class constructor might result in that exception, so the derived constructor must also declare that exception -- even if it has no additional code that might throw anything.
(Note: A constructor might explicitly call this instead of super, but eventually one of the overloaded constructors must call super.)
Thanks Marc for such a beautiful description of constructors and exceptions.
It is quite helpful.
Joined: Feb 20, 2007
I would like to add something that I just cleared my concept about...
If any one thread throws uncaught exception the JVM doesnt exit, all other threads continue normally and do their functionality. This is also true in the case of main thread throwing an exception...ie. all othe threads continue normally even after main thread throws some uncaught exception.
Apart from Exceptions ,this also holds true for throwing Throwable or Error instances...