CSC/ECE 517 Fall 2009/wiki1b 3 b4

Exception-Handling in O-O language

Most major O-O language use the almost the same way to deal with exception occurred during runtime. The mechanism is: When an error occurs within a method, the method creates an object and hand it off to the runtime system. The object, called an exception object, contains information about the error, including its type and the state of the program when the error occurred. Creating an exception object and handing it to the runtime system is calling throwing an exception.

After a method throws an exception, the runtime system attempts to find something to handle it. The set of possible "somethings" to handle the exception is the ordered list of methods that had been called to get to the method where the error occurred. The list of methods is knows as the call stack. The runtime system searches the call stack for a method that contains a block of code that can handle the exception. This block of code is called an exception handler. The search begins with method in which the error occurred and proceeds through the call stack in the reverse order in which the methods were called. When an appropriate handler is found, the runtime system passes the exception to the handler. An exception handler is considered appropriate if the type of the exception object thrown matches the type that can be handled by the handler.

The exception handling mechanism of several major O-O languages are listed below with example provided.

Java

The exception handler chosen is said to catch the exception. If the runtime system exhaustively searches all the methods on the call stack without finding an appropriate exception handler, the runtime system(and, consequently, the program) terminates.

Smalltalk

I get asked about Smalltalk exception handling from time to time, and - specifically - I get asked how it differs from what's done in Java. The primary difference is in how the context stack is handled. In Java, when you get to the handler code, the stack has been unwound and is just gone. Not so in Smalltalk - as a matter of fact, the stack is an argument held in the exception. Here's a simple example - I'll use the NetResources library to try and retrieve a non-existant url, and toss a breakpoint into the handler code so you can see what's going on. Here's the relevant code:

response := [client executeRequestDo: [:connection | client getNotifyingResponse: connection]] on: (self class httpExceptions, Error) do: [:ex | self behaviourForException: ex. nil].

We've wrapped the actual HTTP request in a handler that sends all exceptions to a method called #behaviorForException:. That's done so that we can respond appropriately based on the kind of exception that crops up. Here's that method:

behaviourForException: ex ex class = Security.SSLBadCertificate ifTrue: [Security.X509.X509Registry default addCertificate: ex parameter parameter]. (self class possibleTimeoutExceptions includes: ex class) ifTrue: [self updateCacheResponseCodeOnly. ^self class triggerTimeoutEvent: url]. (ex isResumable and: [self class exceptionsWeShouldResume includes: ex class] ) ifTrue: [ex resume] ifFalse: [self reportTheErrorType: ex]

See that part at the bottom that checks for resumable (and worth resuming) exceptions? If we get there, what will happen is simple - the system will return to the point where the exception got thrown, and simply proceed as if it hadn't happened. You might ask yourself, why would we want to do that? As it happens, there's code in the calling method to handle things like HTTP redirects and Authorization requests - so those exceptions are simply resumed. So anyway, a brief demonstration - here's a screen shot of an attempt to fetch a non-existant URL: