Exceptions in Java

Exceptions in Java

Author: Vadim Lotar
Lohika (2011)

Agenda

• Introduction
• Errors and Error handling
• Exceptions
• Types of Exceptions
• Keywords
• Exceptions handling
• Summary

Introduction
• Customers have high expectations for the code we
produce.
• Users will use our programs in unexpected ways.
• Due to design errors or coding errors, our
programs may fail in unexpected ways during
execution
• It is our responsibility to produce quality code that
does not fail unexpectedly.
• Consequently, we must design error handling into
our programs.

Errors and Error handling
• An Error is any unexpected result obtained from a
program during execution.
• Unhandled errors may manifest themselves as
incorrect results or behavior, or as abnormal
program termination.
• Errors should
be handled by
the
programmer, to
prevent them
from reaching
the user.

• Memory errors (i.e memory incorrectly allocated,
memory leaks…)
• File system errors (i.e. disk is full…)
• Network errors (i.e. network is down…)
• Calculation errors (i.e. divide by 0)
• Array errors (i.e. accessing element –1)
• Conversion errors (i.e. convert „q‟ to a number)
• Can you think of some others?

• Every method returns a value (flag)
indicating either success, failure, or some
error condition.
• Cons: developer must remember to
always check the return value and take
appropriate action.
• Where used: traditional programming
languages (i.e. C) use this method for almost
all library functions

• Create a global error handling routine,
and use some form of “jump” instruction
to call this routine when an error occurs
• Cons: “jump” instruction (GoTo) are
considered “bad programming practice”
and are discouraged
• Where used: many older programming texts
(C, FORTRAN) recommended this method to
programmers.

Exceptions

• Exceptions – a better error handling
• What are they?
• An exception is a representation of an error
condition or a situation that is not the
expected result of a method.
• Exceptions are built into the Java language
and are available to all program code.
• Exceptions isolate the code that deals with the
error condition from regular program logic.

Types of Exceptions
• Unchecked Exceptions • Checked Exceptions
It is not required that these types Must either be caught by a
of exceptions be caught or method or declared in its
declared on a method. signature.

• Runtime exceptions can be • Placing exceptions in the
generated by methods or by method signature harkens
the JVM itself. back to a major concern for
Goodenough.
• Errors are generated from
deep within the JVM, and • This requirement is viewed
often indicate a truly fatal with derision in the
state. hardcore C++ community.

• Runtime exceptions are a • A common technique for
source of major controversy! simplifying checked
exceptions is subsumption.

Types of Exceptions
Throwable The base class for all exceptions.

Error Indicates serious problems that a reasonable application
should not try to catch. Most such errors are abnormal
conditions.
Exception Anything which should be handled by the invoker.

java.lang.Throwable

java.lang.Error java.lang.Exception

java.lang.ThreadDeath java.lang.RuntimeException java.io.IOException

java.lang.NullPointerException java.lang.IllegalArgumentException java.io.FileNotFoundException

Types of Exceptions

• Three Critical Decisions:
• How do you decide to raise an exception rather than return?
1. Is the situation truly out of the ordinary?
2. Should it be impossible for the caller to ignore this problem?
3. Does this situation render the class unstable or inconsistent?

• Should you reuse an existing exception or create a new type?
1. Can you map this to an existing exception class?
2. Is the checked/unchecked status of mapped exception acceptable?
3. Are you masking many possible exceptions for a more general one?

• How do you deal with subsumption in a rich exception hierarchy?
1. Avoid throwing a common base class (e.g. IOException).
2. Never throw an instance of the Exception or Throwable classes.

Keywords
• throws
Describes the exceptions which can be raised by a method.

• throw
Raises an exception to the first available handler in the call
stack, unwinding the stack along the way.

• try
Marks the start of a block associated with a set of exception
handlers.

• catch
If the block enclosed by the try generates an exception of this
type, control moves here; watch out for implicit subsumption.

• finally
Always called when the try block concludes, and after any
necessary catch handler is complete.

Keywords
public void setProperty(String p_strValue) throws
NullPointerException
{
if (p_strValue == null) {throw new NullPointerException(“...”);}
}

public void myMethod() {
MyClass oClass = new MyClass();

try {
oClass.setProperty(“foo”);
oClass.doSomeWork();

} catch (NullPointerException npe) {
System.err.println(“Unable to set property: “+npe.toString());
} finally {
oClass.cleanup();
}
}

Keywords
• throw(s)
/* The IllegalArgumentException is considered unchecked, and
* even making it part of the signature will not alter that. */
public void setName(String p_strName) throws
IllegalArgumentException
{
/* valid names cannot be zero length */
if (p_strName.length() == 0) {
throw new IllegalArgumentException(“…”);
}
m_strName = p_strName;
}

public void foo() {
setName(“”); /* No warning about unhandled exceptions. */
}

Keywords
• throw(s)
/* Make a bad parameter exception class */
class NuttyParameterException extends Exception { … }

/* To really make an invoker pay attention, use a checked
* exception type rather than a Runtime Exception type, but you
must declare that you will throw the type! */
public void setName(String p_strName)
throws NuttyParameterException
{
/* valid names cannot be zero length */
if (p_strName == null || p_strName.length() == 0) {
throw new NuttyParameterException(“…”);
}
m_strName = p_strName;
}
/* Many of us will have an unquenchable desire to use a Runtime
* exception in the above, but resist! */
public void foo() {
setName(“”); /* This does result in an error. */
}

Keywords
• try
/* The try statement marks the position of the first bytecode
instruction
* protected by an exception handler. */
try {
UserRecord oUser = new UserRecord();
oUser.setName(“Mr. XXX”);
oUser.store();

/* This catch statement then marks the final bytecode
instruction protected, and begins the list of exceptions
handled. This info is collected and is stored in the
exception table for the method. */
} catch (CreateException ce) {
System.err.println(“Unable to create user record in the
database.”);
}

Keywords
• catch
/* A simple use of a catch block is to catch the exception
raised by the code from a prior slide. */
try {
myObject.setName(“foo”);
} catch (NuttyParameterException npe) {
System.err.println(“Unable to assign name: “ +
npe.toString());
}

try { /* example 2 */
myObject.setName(“foo”);
} catch (NuttyParameterException npe) { /* log and relay this
problem. */
System.err.println(“Unable to assign name: “ +
npe.toString());
throw npe;
}

Keywords
• catch
/* Several catch blocks of differing types can be concatenated.
*/
try {
URL myURL = new URL("http://www.mainejug.org");
InputStream oStream = myURL.openStream();
byte[] myBuffer = new byte[512];
int nCount = 0;

while ((nCount = oStream.read(myBuffer)) != -1) {
System.out.println(new String(myBuffer, 0, nCount));
}
oStream.close();

} catch (MalformedURLException mue) {
System.err.println("MUE: " + mue.toString());
} catch (IOException ioe) {
System.err.println("IOE: " + ioe.toString());
}

Keywords
• finally
URL myURL = null;
InputStream oStream = null;
/* The prior sample completely neglected to discard the network
* resources, remember that the GC is non-determinstic!! */
try {
/* Imagine you can see the code from the last slide here...
*/

} finally { /* What two things can cause a finally block to be
missed? */
/* Since we cannot know when the exception occurred, be
careful! */
try {
oStream.close();
} catch (Exception e) {
}
}

Keywords
• finally
public boolean anotherMethod(Object myParameter) {

try { /* What value does this snippet return? */
myClass.myMethod(myParameter);
return true;

System.err.println(“Exception in anotherMethod()“
+e.toString());
return false;

} finally {
/* If the close operation can raise an exception,
whoops! */
if (myClass.close() == false) {
break;
} 1. True
} 2. False
return false;
}
3. An exception
4. Non of above

Keywords
• finally
public void callMethodSafely() {

while (true) { /* How about this situation? */
try {
/* Call this method until it returns false.
*/
if (callThisOTherMethod() == false) {
return;
}

} finally { 1. Infinite loop
continue; 2. 1
} 3. 2
} /* end of while */ 4. An exception
}

public boolean callThisOTherMethod() {
return false;
}

Practice
/* Since UnknownHostException extends IOException, the
catch block associated with the former is subsumed. */
try {
Socket oConn = new Socket(“www.sun.com”, 80);
} catch (UnknownHostException ohe) {
}

/* The correct structure is to arrange the catch blocks
with the most derived class first, and base class at
the bottom. */
try {
Socket oConn = new Socket(“www.sun.com”, 80);
} catch (UnknownHostException ohe) {
}

Practice
class MyThread implements Runnable {
public MyTask m_oTask = null;
public void run() {
if (m_oTask == null) {
throw new IllegalStateException(“No work to be
performed!”);
} else {
/* Do the work of the thread. */
}
}
}

public void foo() {
MyThread oThread = new MyThread();
/* There is no way to get the exception from the run()
method! */
new Thread(oThread).start();
/* Good reason for Runtime choice!! */
}

Practice
public interface ITest {
void test() throws IOException ;
}

public class TestImpl implements ITest{

public void test() throws IOException, InvalidArgumentException {
//some code
}

public void test() throws IOException, FileNotFoundException {
//some code
}

public void test() {
//some code
}

public void test() throws IOException {
//some code
}
}

New in Java 7
} catch (FirstException ex) { Multi-catch feature
logger.error(ex); } catch (FirstException | SecondException ex) {
throw ex; logger.error(ex);
} catch (SecondException ex) { throw ex;
logger.error(ex); }
throw ex;
}

Final rethrow
public static void test2() throws ParseException, IOException{
DateFormat df = new SimpleDateFormat("yyyyMMdd");
try {
df.parse("x20110731");
new FileReader("file.txt").read();
} catch (final Exception e) {
System.out.println("Caught exception: " + e.getMessage());
throw e;
}
}

New in Java 7
public class OldTry {
public static void main(String[] args) {
OldResource res = null;
try {
res = new OldResource();
res.doSomeWork("Writing an article");
System.out.println("Exception Message: " +
e.getMessage() + " Exception Type: " + e.getClass().getName());
} finally {
try {
res.close();
System.out.println("Exception Message: " +
e.getMessage() + " Exception Type: " + e.getClass().getName());
}
}
}
}

public class TryWithRes {
public static void main(String[] args) {
try(NewResource res = new NewResource("Res1 closing")){
res.doSomeWork("Listening to podcast");
} catch(Exception e){
System.out.println("Exception: "+
e.getMessage()+" Thrown by: "+e.getClass().getSimpleName());
}
}
}

Summary

• Exceptions are a powerful error
handling mechanism.

• Exceptions in Java are built into the
language.

• Exceptions can be handled by the
programmer (try-catch), or handled by
the Java environment (throws).

Task
• Implement Application
• App takes two parameters from the command
line: the directory path and a file name.
• App should have an ability to find the file in
sub folders too.
• Read data from file and print it
• Every possible error situation should be
handled
• Create an own class which represents an
exception

Exceptions in Java

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Exceptions in Java (20)

Recently uploaded (20)

Exceptions in Java

Editor's Notes