ITI Introduction to Computing II

Similar documents
ITI Introduction to Computing II

Exceptions - Example. Exceptions - Example

EXCEPTION HANDLING. Summer 2018

More on Exception Handling

ECE 122. Engineering Problem Solving with Java

Day 8. COMP1006/1406 Summer M. Jason Hinek Carleton University

BBM 102 Introduction to Programming II Spring Exceptions

Programming II (CS300)

More on Exception Handling

COMP1008 Exceptions. Runtime Error

COMP200 EXCEPTIONS. OOP using Java, based on slides by Shayan Javed

CSC System Development with Java. Exception Handling. Department of Statistics and Computer Science. Budditha Hettige

Exceptions. CSC207 Winter 2017

COMP 213. Advanced Object-oriented Programming. Lecture 17. Exceptions

BBM 102 Introduction to Programming II Spring 2017

Exceptions, try - catch - finally, throws keyword. JAVA Standard Edition

Le L c e t c ur u e e 5 To T p o i p c i s c t o o b e b e co c v o e v r e ed e Exception Handling

CS112 Lecture: Exceptions. Objectives: 1. Introduce the concepts of program robustness and reliability 2. Introduce exceptions

Administration. Exceptions. Leftovers. Agenda. When Things Go Wrong. Handling Errors. CS 99 Summer 2000 Michael Clarkson Lecture 11

Programming II (CS300)

A Third Look At Java. Chapter Seventeen Modern Programming Languages, 2nd ed. 1

CSC207H: Software Design. Exceptions. CSC207 Winter 2018

Pages and 68 in [JN] conventions for using exceptions in Java. Chapter 8 in [EJ] guidelines for more effective use of exceptions.

Exceptions and I/O: sections Introductory Programming. Errors in programs. Exceptions

Introductory Programming Exceptions and I/O: sections

Exception Handling. Exception Handling

Exceptions. References. Exceptions. Exceptional Conditions. CSE 413, Autumn 2005 Programming Languages

C16b: Exception Handling

CS112 Lecture: Exceptions and Assertions

CSCI 261 Computer Science II

Exception in thread "main" java.lang.arithmeticexception: / by zero at DefaultExceptionHandling.main(DefaultExceptionHandling.

Full file at Chapter 2 - Inheritance and Exception Handling

Exceptions. CSE 142, Summer 2002 Computer Programming 1.

Exceptions. Readings and References. Exceptions. Exceptional Conditions. Reading. CSE 142, Summer 2002 Computer Programming 1.

Lecture 19 Programming Exceptions CSE11 Fall 2013

Topic 6: Exceptions. Exceptions are a Java mechanism for dealing with errors & unusual situations

What are Exceptions?

For more details on SUN Certifications, visit

Recitation 3. 2D Arrays, Exceptions

Exceptions and Error Handling

Introduction. Exceptions: An OO Way for Handling Errors. Common Runtime Errors. Error Handling. Without Error Handling Example 1

Chapter 8. Exception Handling. CS 180 Sunil Prabhakar Department of Computer Science Purdue University

Administrivia. CPSC Winter 2008 Term 1. Department of Computer Science Undergraduate Events

Introduction to Computation and Problem Solving. Class 25: Error Handling in Java. Prof. Steven R. Lerman and Dr. V. Judson Harward.

Exception Handling. Sometimes when the computer tries to execute a statement something goes wrong:

Exceptions Handling Errors using Exceptions

Correctness and Robustness

Exception Handling. Run-time Errors. Methods Failure. Sometimes when the computer tries to execute a statement something goes wrong:

What is the purpose of exceptions and exception handling? Vocabulary: throw/raise and catch/handle Exception propagation Java checked and unchecked

About This Lecture. Outline. Handling Unusual Situations. Reacting to errors. Exceptions

Binary search. int index = Collections.binarySearch(list, element);

A problem?... Exceptions. A problem?... A problem?... Suggested Reading: Bruce Eckel, Thinking in Java (Fourth Edition) Error Handling with Exceptions

Exception-Handling Overview

Here is a hierarchy of classes to deal with Input and Output streams.

CS1020 Data Structures and Algorithms I Lecture Note #8. Exceptions Handling exceptional events

Chapter 12 Exception Handling

CS115. Chapter 17 Exception Handling. Prof. Joe X. Zhou Department of Computer Science. To know what is exception and what is exception handling

Programming Languages and Techniques (CIS120)

Defensive Programming. Ric Glassey

COE318 Lecture Notes Week 10 (Nov 7, 2011)

National University. Faculty of Computer Since and Technology Object Oriented Programming

Input-Output and Exception Handling

Chapter 13 Exception Handling

CSE 331 Software Design & Implementation

Software Practice 1 - Error Handling

CS 3 Introduction to Software Engineering. 3: Exceptions

Exception Handling. Chapter 11. Java By Abstraction Chapter 11. Outline What Are Exceptions?

Object Oriented Programming Exception Handling

To Think About. MyClass.mogrify(new int[] { 1, 2, 4, 6 }));

Fundamentals of Object Oriented Programming

COSC Exception Handling. Yves Lespérance. Lecture Notes Week 10 Exception Handling

Exception Handling. Chapter 11. Outline. Example: The Quotient app What Are Exceptions? Java By Abstraction Chapter 11

17. Handling Runtime Problems

Errors and Exceptions

Exceptions vs. Errors Exceptions vs. RuntimeExceptions try...catch...finally throw and throws

CS159. Nathan Sprague

Checked and Unchecked Exceptions in Java

An exception is simply an error. Instead of saying an error occurred, we say that an.

CSE 143 Java. Exceptions 1/25/

EXCEPTION-HANDLING INTRIVIEW QUESTIONS

Exception Handling. General idea Checked vs. unchecked exceptions Semantics of... Example from text: DataAnalyzer.

6.Introducing Classes 9. Exceptions

School of Informatics, University of Edinburgh

Assoc. Prof. Marenglen Biba. (C) 2010 Pearson Education, Inc. All rights reserved.

Introduction to Software Design

SECTION-1 Q.1.Which two code fragments are most likely to cause a StackOverflowError? (Choose two.)

Module 4 - 异常和断言 一 选择题 :

Lecture 14 Summary 3/9/2009. By the end of this lecture, you will be able to differentiate between errors, exceptions, and runtime exceptions.

CS 61B Data Structures and Programming Methodology. July 7, 2008 David Sun

Introduction to Java Written by John Bell for CS 342, Spring 2018

EXCEPTION HANDLING. // code that may throw an exception } catch (ExceptionType parametername) {

EXCEPTIONS. Objectives. The try and catch Statements. Define exceptions. Use try, catch and finally statements. Describe exception categories

Object Oriented Programming

Object Oriented Programming

Lecture 28. Exceptions and Inner Classes. Goals. We are going to talk in more detail about two advanced Java features:

2.6 Error, exception and event handling

EXCEPTIONS. Java Programming

Projeto de Software / Programação 3 Tratamento de Exceções. Baldoino Fonseca/Márcio Ribeiro

CSC 1214: Object-Oriented Programming

Exception Handling in Java. An Exception is a compile time / runtime error that breaks off the

Transcription:

ITI 1121. Introduction to Computing II Marcel Turcotte School of Electrical Engineering and Computer Science Version of February 23, 2013 Abstract Handling errors Declaring, creating and handling exceptions Checked and unchecked exceptions Creating new exception types These lecture notes are meant to be looked at on a computer screen. Do not print them unless it is necessary.

Error processing Errors can occur at compile-time or runtime. Syntax errors are detected at compile time. Since Java is a strongly typed language, the compiler will also ensure that each expression is valid, i.e. only valid operations for this data type are performed, avoiding errors that would otherwise occur during the execution of the program. Although type checking is an efficient way of detecting errors as soon as possible, there are certain verifications that can only be made at execution time; e.g. checking that a stack contains an element before removing it. In Java, runtime errors are handled by a mechanism called Exceptions.

Sources of errors Logic of the program; External events: running out of memory, write error, etc. Detecting and handling errors will make our programs more robust. Ideally, those mechanisms should help locating precisely the source of the errors. For instance, the method pop of the ArrayStack implementation, could throw an IndexOutOfBoundsException. Is the source of the error necessarily in the method pop? No. In fact, it is likely that the error situation occurred because the caller did not check if the stack was empty before calling the method pop.

Pre-conditions Pre-conditions are the ensemble of conditions that the parameters and the state of the object, must verify so that the computation can be successful. A familiar example is the calculation of the square root of a number. The pre-condition is that the parameter be a non-negative number. Depending on the programming language used or the library, the validity of the calculation is not guaranteed: some programs may loop, others may crash. In the case of ArrayStack, an attempt to remove an element when the stack is empty is an example of an error condition; here, the state of the object was inconsistent with the actual goal of the method pop. It s a good programming habit to always think about the preconditions of a method. From now on, try to identify the preconditions when writing a method.

Of the value of top...

Handling errors What should we do? Crash the program (e.g. 1/0), exit,... certainly not. Write an error message? Good idea but it is not enough. Traces are useful during the development of a program but should be removed from its final version.

Handling errors It would be possible to return a special value, sentinel, whenever an error is detected. Analogy. Search by content methods return the index of the element that is sought and -1 if not found. However, the solution is not general enough, nor effective. Some methods don t have a return value or don t have special values that can be used; think of a method that returns a boolean value, member(x) of a list; The caller is not forced to handle the error situation.

Handling errors Error handling is a general problem and modern languages offer solutions. In Java the mechanism is called Exceptions. Exceptions are objects.

Exception is a class Object Throwable message: String +getmessage(): String +printstacktrace(): void +String(): tostring Error Exception IOException... RuntimeException IllegalArgumentException NullPointerException ArithmeticException IllegalStateException IndexOutOfBoundsException NumberFormatException

The Exceptions are objects! Exception is a class An error situation is modelled using an object of the class Throwable, or one of its sub-classes. The object encapsulates the error message. The class Throwable declares the methods String getmessage() and void printstacktrace(). Declaring a reference of type Exception (it s simply a class), Exception e; Creating an object of the class Exception (it s simply a class), e = new Exception( "Houston, we have a problem!" );

Signaling an error Consider the class ArrayStack and its method pop(). The empty stack is an illegal case (illegal state). Since we didn t have better tools we used to insert a comment indicating the necessary pre-condition: // if ( top == -1 ) BOOM! In Java, the way to handle illegal cases is to throw an exception. if ( top == -1 ) { throw new IllegalStateException( "Empty stack" );

Throw statement: throw expression where expression is a reference to an object of the class Throwable, or one of its subclasses. IllegalStateException e; e = new IllegalStateException( "Empty stack" ); if ( top == -1 ) { throw e; It s throw that changes the flow of control! Not the declaration, not the creation of the object.

When an Exception is thrown: Transfer of control The statement or expression terminates abruptly; If uncaught, the Exception will cause the whole stack of method calls to unwind, i.e. each method call on the stack will terminate abruptly. If the exception is not caught the program (thread) will terminate and print a stack trace; None of the statements or parts of the expression that follow the point where the exception was thrown are executed; Following an exception the next statements to be ran will be those of a catch or finally block.

public class Test { public static void main( String[] args ) { System.out.println( "-1-" ); throw new RuntimeException( "an Exception" ); System.out.println( "-2-" ); Does not compile. Why? Ways around the problem? javac Test.java Test.java:8: unreachable statement System.out.println( "-2-" ); ^ 1 error

Once an Exception has occurred the method terminates abruptly. class Test { public static void main ( String[] args ) { System.out.println( "-1-" ); if ( true ) { throw new RuntimeException( "Help!" ); System.out.println( "-2-" ); > java Test -1- Exception in thread "main" java.lang.runtimeexception: Help! an Exception at Test.main(Test.java:5) Notice that -2- has not been printed!

Not even the remaining part of an expression is executed. public class Test extends Object { public static boolean error() { if ( true ) { throw new RuntimeException( "an Exception" ); return true; public static boolean display() { System.out.println( "-2-" ); return true; public static void main( String[] args ) { System.out.println( "-1-" ); if ( error() display() ) { System.out.println( "-3-" ); System.out.println( "-4-" );

> java Test -1- Exception in thread "main" java.lang.runtimeexception: an Exception at Test.error(Test.java:5) at Test.main(Test.java:16)

Unwinding the stack of method calls: public class Test { public static void c() { System.out.println( "c: -1-" ); if ( true ) { throw new RuntimeException( "top of the world!" ); System.out.println( "c: -2-" ); public static void b() { System.out.println( "b: -1-" ); c(); System.out.println( "b: -2-" ); public static void a() { System.out.println( "a: -1-" ); b(); System.out.println( "a: -2-" ); public static void main( String[] args ) { System.out.println( "m: -1-" ); a(); System.out.println( "m: -2-" );

> java Test m: -1- a: -1- b: -1- c: -1- Exception in thread "main" java.lang.exception: top of the world! top of the stack at Test.c(Test.java:6) at Test.b(Test.java:11) at Test.a(Test.java:16) at Test.main(Test.java:21)

Handling Exceptions Statements that can throw an exception are enclosed in a try/catch block: try { statements; catch ( exception_type1 id1 ) { statements; catch ( exception_type2 id2 ) { statements;... finally { statements; If no exception occurs only the statements of the try (and finally) block(s) are executed.

public class Grill { private Burner burner = new Burner(); public void cooking() { try { burner.on(); addsteak(); addsaltandpepper(); boolean done = false; while (! done) { done = checksteak(); catch ( OutOfGazException e1 ) { callretailer(); catch ( FireException e2 ) { extinguishfire(); finally { burner.off();

int DEFAULT_VALUE = 1; int value; try { value = Integer.parseInt( "100" ); catch ( NumberFormatException e ) { value = DEFAULT_VALUE; System.out.println( "value = " + value ); prints value = 100.

public static int parseint(string s) throws NumberFormatException Parses the string argument as a signed decimal integer. The characters in the string must all be decimal digits, except that the first character may be an ASCII minus sign - ( \u002d ) to indicate a negative value. The resulting integer value is returned, exactly as if the argument and the radix 10 were given as arguments to the parseint(java.lang.string, int) method. Parameters: s - a String containing the int representation to be parsed Returns: the integer value represented by the argument in decimal. Throws: NumberFormatException - if the string does not contain a parsable integer.

int DEFAULT_VALUE = 1; int value; try { value = Integer.parseInt( "Team A" ); catch ( NumberFormatException e ) { value = DEFAULT_VALUE; System.out.println( "value = " + value ); prints value = 1.

If an exception is thrown, the statements of the first catch block that matches the exception are executed. Match means that the exception is of the specified type or a subtype of it. No other block will be executed. If no catch matches the exception it percolates outside the try block. Statements in the finally block are always executed. Blocks finally are used to close files, for example.

Catch expressions must be as specific as possible. int DEFAULT_VALUE = 1; int value; try { value = Integer.parseInt( "a" ); catch ( Exception e ) { value = DEFAULT_VALUE; System.out.println( "value = " + value ); Why? The block above would catch any Exception type. However, the catch statement is not designed to handle any Exception, what should it do if a ClassNotFoundException occurred?

It should let it percolate so that an enclosing block can catch it.

public class Test { public static void c() { System.out.println( "c() :: about to throw exception" ); throw new RuntimeException( "from c()" ); public static void b() { System.out.println( "b() :: pre-" ); c(); System.out.println( "b() :: post-" ); public static void a() { System.out.println( "a() :: pre-" ); try { b(); catch ( RuntimeException e ) { System.out.println( "a() :: caught exception" ); System.out.println( "a() :: calling b, no try block" ); b(); System.out.println( "a() :: post-" ); public static void main( String[] args ) { System.out.println( "main(... ) :: pre-" ); a(); System.out.println( "main(... ) :: post-" );

main(... ) :: prea() :: preb() :: prec() :: about to throw exception a() :: caught exception a() :: calling b, no try block b() :: prec() :: about to throw exception Exception in thread "main" java.lang.runtimeexception: from c at Test.c(Test.java:4) at Test.b(Test.java:8) at Test.a(Test.java:19) at Test.main(Test.java:24)

Exercise public class Test { public static void c() { System.out.println( "c() :: about to throw exception" ); throw new RuntimeException( "from c()" ); public static void a() { System.out.println( "a() :: pre-" ); try { c(); catch ( NumberFormatException e ) { System.out.println( "a() :: caught exception" ); finally { System.out.println( "finally" ); System.out.println( "a() :: calling b, no try block" ); c(); System.out.println( "a() :: post-" ); public static void main( String[] args ) { System.out.println( "main(... ) :: pre-" ); a(); System.out.println( "main(... ) :: post-" );

class Test { public static void main( String[] args ) { boolean valid = false; int value = -1; for ( int i=0; i<args.length &&! valid; i++ ) { try { value = Integer.parseInt( args[i] ); valid = true; catch ( NumberFormatException e ) { System.out.println( "not a valid number: " + args[i] ); if ( valid ) { System.out.println( "value = " + value ); else { System.out.println( "no valid number was found" );

> java Test a 1.1 "" 2 3 not a valid number: a not a valid number: 1.1 not a valid number: value = 2

int DEFAULT_VALUE = 1; int value; try { value = Integer.parseInt( "a" ); catch ( NumberFormatException e ) { System.out.println( "warning: " + e.getmessage() ); value = DEFAULT_VALUE; e is a reference to the object that was thrown, like any reference variable you can select the name you want, here we re calling the method getmessage() of the exception designated by e.

Object Throwable message: String +getmessage(): String +printstacktrace(): void +String(): tostring Error Exception IOException... RuntimeException IllegalArgumentException NullPointerException ArithmeticException IllegalStateException IndexOutOfBoundsException NumberFormatException There are checked and unchecked exceptions. All the exceptions that are subclasses of Throwable are unchecked (default). Except those that are subclasses of Exception, those are checked. Except those that are from a subclass of RuntimeException, which are unchecked.

Checked and unchecked exceptions A method that throws a checked exception must declare or handle the exception. class Test { public static void main( String[] args ) { System.out.println( "-1-" ); if ( true ) { throw new Exception( "an Exception" ); System.out.println( "-2-" ); > javac Test.java Test.java:5: unreported exception java.lang.exception; must be caught or declared to be thrown throw new Exception("an Exception");

^

Checked and unchecked exceptions A method that throws a checked exception must declare or handle the exception. class Test { public static void main( String[] args ) throws Exception { System.out.println( "-1-" ); if ( true ) { throw new Exception( "an Exception" ); System.out.println( "-2-" );

Checked and unchecked exceptions Unchecked exceptions include NullPointerException and IndexOutOfBounds- Exception. Any method that declares a reference variable can potentially throw a NullPointerException! Similarly, any method that uses an array can potentially throw a IndexOutOfBoundsException! Under normal circumstances (i.e. unless there is a bug) these methods should not be throwing exceptions. Java does not require you to declare (or catch) unchecked exceptions.

Checked and unchecked exceptions Checked exceptions are used to force the caller to define a strategy for handling these exceptions (declare or catch). An example of a checked exception is IOException. Often used to deal with situations caused by external events: read/write error. Used in contexts where the caller can take actions to handle the error.

Handling exceptions Methods that could potentially throw checked exceptions must declare the exceptions. Catching an exception; Declaring an exception (throws). public static void main( String[] args ) throws IOException, FileNotFoundException, IllegalAccessException {...

Handling exceptions A method can declare checked and unchecked exceptions; the declaration of unchecked exceptions is optional. public static void main( String[] args ) throws IOException, FileNotFoundException, NullPointerException {... Here, NullPointerException, an unchecked exception, is optional.

Transitive effects (1/5) import java.io.*; public class Keyboard { public static int getint() { byte[] buffer = new byte[ 256 ]; System.in.read( buffer ); // throws IOException String s = new String( buffer ); int num = Integer.parseInt( s.trim() ); return num; public static void main( String[] args ) { System.out.print( "Please enter a number: " ); int n = Keyboard.getInt(); System.out.println( "You ve entered the number: " + n );

Transitive effects (1/5) > javac Keybord.java Keyboard.java:9: unreported exception java.io.ioexception; must be caught or declared to be thrown System.in.read(buffer); ^ 1 error

Transitive effects (2/5) import java.io.*; public class Keyboard { public static int getint() throws IOException { byte[] buffer = new byte[ 256 ]; System.in.read( buffer ); // throws IOException String s = new String( buffer ); int num = Integer.parseInt( s.trim() ); return num; public static void main( String[] args ) { System.out.print( "Please enter a number: " ); int n = Keyboard.getInt(); // throws IOException System.out.println( "You ve entered the number: " + n );

Transitive effects (2/5) > javac Keyboard.java Keyboard.java:22: unreported java.io.ioexception; must be caught or declared to be thrown int n = Keyboard.getInt(); ^ 1 error

Transitive effects (3/5) import java.io.*; public class Keyboard { public static int getint() throws IOException { byte[] buffer = new byte[ 256 ]; System.in.read( buffer ); // throws IOException String s = new String( buffer ); int num = Integer.parseInt( s.trim() ); return num; public static void main( String[] args ) throws IOException { System.out.print( "Please enter a number: " ); int n = Keyboard.getInt(); // throws IOException System.out.println( "You ve entered the number: " + n );

Transitive effects (3/5) > java Keyboard Please enter a number: oups Exception in thread "main" java.lang.numberformatexception For input string: "oups" at java.lang.numberformatexception. forinputstring(numberformatexception.java:48) at java.lang.integer.parseint(integer.java:468) at java.lang.integer.parseint(integer.java:518) at Keyboard.getInt(Keyboard.java:13) at Keyboard.main(Keyboard.java:23)

throws A method that can possibly throw checked 1 Exceptions, i.e.: throws an Exception itself; or calls a method that throws an exception and the exceptions are not caught by a block finally or catch, must declare all those exceptions: void method() throws EOFException, FileNotFoundException {... 1 not a subclass of Error or RuntimeException

Creating New Exception Types Extends Exception or one of its subclasses. Extending Exception (or one of its subclasses, except the subclasses of RuntimeException) is creating a checked exception. Extending RuntimeException (or one of its subclasses) is creating an unchecked exception.

public class MyException extends Exception { public class MyException extends Exception { public MyException() { super(); public MyException( String message ) { super( message ); Why creating new types?

To specialize an exception, or to add new implementation details. Because exceptions are caught selectively using their type (filter). try {... catch ( Exception e ) { // can you really handle any type of error? try {... catch ( NumberFormatException e ) { var = DEFAULT_VALUE; To document the program and its execution.

Class Time In the following example, the method parsetime catches NumberFormatException and NoSuchElementException, and throws a more informative type, TimeFormatException. public class TimeFormatException extends IllegalArgumentException { public TimeFormatException() { super(); public TimeFormatException( String msg ) { super( msg );

public class Time { //... public static Time parsetime( String timestring ) { StringTokenizer st = new StringTokenizer( timestring, ":", true ); int h, m, s; try { h = Integer.parseInt( st.nexttoken() ); catch( NumberFormatException e1 ) { throw new TimeFormatException( "first field is not a number"); catch( NoSuchElementException e2 ) { throw new TimeFormatException( "first separator not found" ); try { st.nexttoken(); catch( NoSuchElementException e2 ) { throw new TimeFormatException( "first separator not found" );

try { m = Integer.parseInt( st.nexttoken () ); catch( NumberFormatException e1 ) { throw new TimeFormatException( "second field is not a number" ); catch( NoSuchElementException e2 ) { throw new TimeFormatException( "second separator not found" ); try { st.nexttoken(); catch( NoSuchElementException e2 ) { throw new TimeFormatException( "second separator not found" ); try { s = Integer.parseInt( st.nexttoken() ); catch( NumberFormatException e1 ) { throw new TimeFormatException( "third field is not a number" ); catch( NoSuchElementException e2 ) { throw new TimeFormatException( "third field not found" );

if ( st.hasmoretokens() ) throw new TimeFormatException( "invalid suffix ); if ( (h<0) (h>23) (m<0) (m>59) (s<0) (s>59) ) throw new TimeFormatException( "values out of range:" + timestring ); return new Time( h,m,s );

Error message throw new Exception( "meaningful message" );

Remarks Use existing exception types as much as possible instead of defining new ones. Have clear messages. Since programs can recuperate from exceptions make sure that the state of objects remain consistent.