- Exceptions come in two flavors: checked and unchecked.
- Checked exceptions include all subtypes of exception, excluding the classes that extend Runtime exception.
- Checked exceptions are subject to the handle or declare rule: any method that might throw a checked exception (including methods that invoke methods that can through a checked exception) must either declare the exception using throws, or handle the exception with an appropriate try/catch block.
- Subtypes of error and Runtime Exceptions are unchecked.so the compiler dosent enforce the handle or declare rule, you are free to handle them, or to declare them, but the compiler dosent care one way or the other.
- If you us optional finally block, it will always be invoked, regardless of whether an exception in the corresponding try is thrown or not, and regardless of whether a thrown exception is caught or not.
- The only exception to the finally will always be called rule is that a finally will not be invoked if the JVM shuts down. That could happen if code from try or catch block calls system.exit();
- Just because of finally is invoked does not mean it will complete. Code in finally block could itself raise exception or issue a system.exit().
- Uncaught exceptions propagate back through the call catch, starting from the method where the exception is thrown and ending with either the first method that has a corresponding catch for that exception type or a JVM shutdown (which happens if the exception gets to main(), and main() is “ducking” the exception by declaring it).
- You can create your exception, normally by extending Exception or one of its subtypes, your exception will be considered a checked exception, and the compiler will enforce the handle or declare a rule for that exception.
- All catch blocks must be ordered from most specific to most general.
- If you have catch clause for both IOException and
Exception you must put the catch for IOException first in your code otherwise the IOException would be caught by catch (Exception e), because a catch argument can catch the specified exception or any of its subtypes the same exceptions are created by programmers, same by the JVM.
Working with the Assertion Mechanism:
- Assertion gives a way to test your assumptions during development and debugging.
- Assertions are typically enables during testing but disables during deployment.
- You can use assert as a key word (as of version 1.4) or an identifier, but not both together. To compile older code that use assert as an identifier ( for example, a method name) , uses the -source 1.3 command line flag to javac.
- Assertions are disabled at runtime by default. To enable them, use a command line flaf –ea of –enableassertions.
- Selectively disable assertions by using the –da or –disableassertions.
- If you enable or disable assertions using the flag without any arguments, you are enabling or disabling assertions in general, you can combine enabling and disabling switched to have assertions enabled for classes and /or packages, but not other.
- You can enable and disable assertions on a class-by-class using the following syntax.
Java –ea –aMyClass TestClass
- You can enable and disable assertions on a package-by-package basis , an a any package you specify also includes any sub package(packages further down the directory hierarchy)
- Do not use assertions to validate arguments to public methods.
- Do not uses assert expressions that cause side effects? Assertions aren’t guaranteed to always run, and you don’t want behavior that changes depending weather assertion are enabled.
- Do not use assertions even in public methods to validate that a particular code block will never be reached.
- You can use assert false; for code that should never be reached, so that an assertion error is thrown immediately if the assert statement is executed.