Gestion des exceptions : syntaxe

Loading...

En provenance du cours de École Polytechnique Fédérale de Lausanne

Introduction à la programmation orientée objet (en Java)

140 notes

École Polytechnique Fédérale de Lausanne

Introduction à la programmation orientée objet (en Java)

140 notes

Ce cours introduit la programmation orientée objet (encapsulation, abstration, héritage, polymorphisme) en l'illustrant en langage Java. Il présuppose connues les bases de la programmation (variables, types, boucles, fonctions, ...). Il est conçu comme la suite du cours « Initiation à la programmation (en Java) ». Comme son prédécesseur, ce cours s'appuie sur de nombreux éléments pédagogiques : vidéos sous-titrées, quizz dans et hors vidéos, exercices, devoirs notés automatiquement, notes de cours.

À partir de la leçon

Gestion des exceptions

Nous étudions cette semaine comment gérer, au moyen du mécanisme des exceptions, des situations anormales pouvant survenir lors de l'exécution d'un programme.

Gestion des exceptions : introduction14:17

Gestion des exceptions : syntaxe23:48

Gestion des exceptions : compléments16:31

Rencontrer les enseignants

Jamila Sam
Dr
School of Computer and Communication Sciences
Jean-Cédric Chappelier
Dr.
School of Computer and Communication Sciences

In the previous episode, you learned

that when we want to generate exceptions in Java,

we basically seek to do four things.

Signalling errors at the place they occur.

Marking places that we want to make receptive for errors,

and associating to each of these places a way of handling these errors.

This is a big advantage of exception handling

We separate error handling

from the place where they occur.

Finally, the fourth thing we might want to do

is possibly to clean up after each error-aware bloc.

We will thus have four words in the language

that will be dedicated to each of these elementary tasks

that we want to take care of.

In this episode, we will present how to use

each of these four words one by one

starting of course with the <i>throw</i> keyword which allows us to indicate an error.

We will say that <i>throw</i> throws an exception

The syntax of <i>throw</i> to throw an error,

to signal an error, is the following.

<i>throw</i> then an exception.

What is an exception?

It is an object of type Exception.

The Exception type is a type which exists in the Java API

and which is provided by the <i>java.lang</i> library

that contains many subclasses which we will present in a moment.

So an exception is an object of type <i>Exception</i>

which, when the <i>throw</i> statement is executed,

is, so to speak, thrown.

This means that there is a mechanism which will create such an object

that will be able to be handled by the other keywords

in the exception handling mechanism.

This is what it means to "throw an exception".

There is a fairly special treatment of these peculiar objects,

these errors to be handled, on the level of the program.

For example, we could have a line such as this one:

<i>throw new Exception</i>, so we create a new exception

Then for example, by calling its constructor

taking as parameter a character string

indicating an error message, "Quelle Erreur!". (TN: means "What an error!").

This message is now associated to this new instance

of the Exception class.

What does it really mean to "throw an exception"?

It means that the <i>throw</i> statement

will skip the normal execution sequence of the program

and will jump either to the next <i>catch</i> bloc directly linked to a <i>try</i> bloc.

We will talk about catch and try in a moment.

For the moment, the important part to remember is that it will jump

to another place in the program.

Or, if there is no such try/catch bloc,

then the program will exit entirely

by ending with what we call an exception.

So <i>throw</i> throws an instance of the Exception class.

This Exception class is itself a subclass of the Throwable class

that inherits from Object.

Exception is not the only subclass of Throwable

that has multiple subclasses

whose goal is to indicate different types of possible errors or exceptions.

For example, there is the Error subclass

which has 12 direct subclasses

and which serves for example to indicate memory errors.

The error class serves to indicate fatal errors

which are not supposed to be used, to be handled by the programmer

with a try/catch bloc.

On the other hand, we have Exceptions, which must or can be

handled by the programmer.

The Exception class has 75 direct subclasses

among which there are 74 Checked Exceptions

which must be treated by the programmer.

They indicate exceptional circumstances,

often, but not always, errors

They must thus be handled at the level of the program with a try/catch bloc.

There is also the RunTimeException subclass,

whose treatment is not necessarily handled by the programmer.

We call these Unchecked Exceptions,

and they have 49 direct subclasses

to treat different error cases that can be avoided with good programming,

such as, for example, indices that exceed an array's length,

or divisions by 0, etc.

This sort of error can be handled by the programmer,

but it is not strictly necessary.

Actually, the next episode will go over these Checked/Unchecked Exceptions

and how to handle them.

At the more general level, right at the top of the hierarchy,

the Throwable class offers two constructors,

one default constructor and one constructor that allows to indicate

an error message in the form of a string.

It offers, among others, two interesting methods,

a <i>getMessage</i> method that allows us to retrieve the error message

initialized using this constructor,

and a <i>printStackTrace</i> method which allows us to display the stack

in the terminal, that is, the sequence of events which led to the error.

That's it for the <i>throw</i> statement.

Now, let's move on to the <i>try</i> statement.

We have seen that if the <i>throw</i> statement is not caught,

that is, not handled by a try/catch bloc, the program is ended.

So in many cases, we will want

-- especially for Checked Exceptions --

we will want to handle them with an exception-handling bloc.

This is exactly what try is used for.

try makes portions of code

compatible with exception handling.

Suppose that I call a method <i>f</i> which can throw exceptions.

Either it can throw exceptions directly

or it can call methods that call methods

that call methods that throw exceptions.

No matter the depth of the call,

in this call to the method <i>f</i>, we have a throw.

Somewhere below this call, we will have a throw.

Then, if such an expression

if such a call to a method that can throw exceptions

is in a bloc that is declared as a try bloc,

then we will be able to setup

an exception-handling mechanism

and so the throw which exists somewhere here, below,

will finally jump to the next catch bloc associated to the try bloc

in which we are requesting exception handling.

catch is thus simply the keyword that is used to introduce

the set of instructions we wish to execute

in order to handle the exceptions.

Every try bloc must have at least one catch bloc associated to it.

We will see in a moment that it can have several.

These must handle the exceptions thrown in the try bloc.

If an exception is thrown by a throw statement,

but is not intercepted by a catch,

if there is no try and no catch corresponding to the exception

that is thrown, then

the program will halt and indicate that an exception

was thrown and it will display where it was thrown,

indicating that this exception was thrown but not caught.

The syntax of a catch bloc starts with the word <i>catch</i>

followed, as with method headers,

the type and the equivalent of a parameter, in parentheses.

We will only have one parameter for this catch header.

Then, behind this, we have the bloc with the instructions that we want to execute

for all exceptions of the type we specify.

It is best to look at an example.

Here, we have a set of instructions that we want to make aware

of exception handling with a try,

and right behind it, we will have a catch statement to catch the exceptions

of type <i>ArithmeticException</i>

and another catch bloc that is also associated to this <i>try</i> bloc

to catch very general exceptions of type <i>Exception</i>.

So here, in this bloc, we could have a variable <i>age</i>,

and if the age is too high, then we will throw a very general exception.

And if the age is lower than 150, we will continue execution.

We would have another variable, <i>x</i>.

If <i>x</i> equals 0, then we throw an <i>ArithmeticException</i>

Otherwise, we continue.

This <i>ArithmeticException</i> will be intercepted by this catch here.

We will execute the instructions that are here and display

the error message that we had put in the <i>ArithmeticException</i>,

then, for example, print the call stack.

However, if it is this very general exception that is thrown,

it is this catch which will be executed.

At that moment, we will display a message, for example:

"Who can live to be that old?"

An important thing to note is that catch blocs associated to a try bloc

will be sorted by level of exception, from least to most general.

We will first have exceptions that are very specific,

then the most general exceptions.

Remember that there is a hierarchy in exceptions, like so.

The processing in the catch will have to start

by the most specific exceptions,

then go to more and more general ones.

If you place catch blocs with the most general exceptions first,

you will get a compiler error.

Now, let's see in detail how all of this is executed.

What is the flow of execution?

What do we do in the different possible cases?

If the exception is thrown; if it is not thrown.

First, the general principles are as follows.

A catch bloc is executed only if an exception corresponding

to the type specified in the catch is thrown

from the corresponding try bloc.

Otherwise, the catch bloc is simply ignored.

We will not execute what is in this catch bloc.

In the absence of a finally, of which we will speak in a moment.

If the catch bloc is executed, then the execution of the program

continues after the catch bloc.

In no case do we come back to the try.

We will continue after the catch bloc.

For example, if we have a try bloc that is made aware

of exception handling,

in which is executed -- either directly

or through a method call --

in which an exception is thrown.

If this exception is thrown, if this line is actually executed,

then at the end of this line, we will jump straight here

to the first line of the catch bloc directly following the try bloc

and corresponding to the type of the exception.

Here, where the type corresponds.

So the exception will be as follows:

We arrive here. We execute this exception throwing

We jump to this place here if an exception was thrown

If however no exception was thrown

that is, if this line here was not executed,

for example, because it was protected by an <i>if</i>

whose condition was not true

then, we execute the code

This line is not executed.

So we continue, of course, by executing the whole bloc.

Let's suppose that there is no throw farther on.

Once we arrive at the end of the bloc, here, we will continue

with the normal execution of the program.

We will simply ignore the whole catch bloc

that is executed only if an exception of the corresponding

type was thrown.

On the example we had earlier,

the flow of execution would be this:

Suppose that in the beginning, we have an <i>age</i> variable,

and that the age, to start off with, is not bigger than or equal to 150.

The age is lower than 150.

Thus, we continue.

We do not go into the if bloc, we do not see the throw, we continue.

Suppose that we have a variable <i>x</i> here, which is not equal to 0.

At this point, we continue normally. We arrive here.

So if no exception was thrown,

"case n°1 : no exception thrown"

then we will continue the execution down here.

This is what happens if the age is under 150

and if x is not equal to 0.

Now, let's see what happens if, for example, the age

is still below 150 but <i>x</i> is 0.

What will happen is that, since the age is under 150,

we do not enter the <i>if</i>, we continue

Here, since x is worth 0, this condition is verified.

We execute this throw, which means that, from here,

we will plug into the exception that was thrown

We threw an ArithmeticException,

so we will jump to the bloc that catches ArithmeticException.

Here, we will continue the execution

by displaying the associated message and by displaying the call trace

Once we have done all of this, then

we will continue with the normal execution after all the catch blocs

associated to the relevant try blocs.

Third and last case, if the age is bigger than or equal to 150.

What will happen is that we will arrive in this if, whose condition is true

so we will execute this exception throwing.

So here, we throw an object of type Exception.

Which means that from here, we will jump to the catch

that handles Exceptions.

This flow will continue here by executing the display of

"Who can live to be that old?"

Then, as always, the execution will continue normally

with the remainder of the program.

Let's go over a third example

where we will put throw, try and catch in one same method.

This is a special case that can nevertheless be useful.

So here, we have a <i>lireEntier</i> (TN: means "readInteger") method

whose goal is to read an integer and return it

and that takes as parameter a maximum number of attempts,

and whose header must be extended with this syntax, <i>throws Exception</i>

which we will explain later on.

So here, we have the whole body of this method

in which, as you can see, we have a try bloc,

to try to read an integer from the keyboard.

We want to read an integer.

What we will do is intercept any throw that could occur

when we try to read this integer, in case the input fails.

This happens, for example, if the user inputs something else,

for example a character string.

In this case, the input will throw an exception of type InputMismatchException

which is defined in the java.util library.

If the input fails, then an exception of that type will be thrown,

so we will jump to the catch, since we had put that in a try bloc.

This will allow us, for example, to display a message

"Try again to input an integer."

Then, with this expression, we clear the input buffer

of the characters left by the previous, bad input.

Finally, we increment the number of tries.

The program will thus execute in the following way.

In the beginning, <i>nbEssais</i> has a value of 1 (TN: "nbEssais" means "number of attempts")

We will be in a loop while the number of attempts

is lesser than or equal to the maximum number of attempts we received as a parameter.

We ask for an integer.

We try to read an integer and each time this input fails

we will jump to the catch bloc which handles the corresponding exception

So we arrive here at the end of the catch bloc if we had an input error.

We continue the execution.

We continue as long as nbEssais has not reached the maximum number of attempts.

In case the input works, no exception is thrown.

So the execution continues normally.

We return the value that was read and we exit the program at that level.

Finally, if we make so many mistakes that we exceed the maximum number of attempts,

the following will happen:

we will have another error which will throw the exception

which will be caught by this catch here.

We will increment the number of attempts.

At the end of the catch, we continue with the normal execution.

But this time, nbEssais will be larger than

maxEssais.

So we will exit the <i>while</i> loop and continue execution

by throwing a new exception this time,

and this exception will be passed on higher to other methods

that will have called lireEntier and that could possibly

catch this exception and handle it.

Let's end with a few remarks.

First, since Java 7 there exists something that is called multi-catch.

We can write: catch Exception1 or Exception2, etc.

Then, something that I already told you,

when you have several catch blocs,

you must absolutely always write them from the most specific

exception, from the lowest one in the exception hierarchy,

to the most general one,

that is, the highest one

in the inheritance relationship of exceptions.

Finally, let's end this episode on Java syntax

for exception handling by this point number 4,

where we might want to cleanup after a catch bloc

with the <i>finally</i> keyword which indicates, optionally, what to do

after an error-handling bloc.

This finally keyword thus controls a bloc which is optional

and which follows the catch blocs associated to a try

and which contains code that should be executed

whether an exception was thrown or not.

The point of this bloc is to clean up,

for example to close files, close connections etc.

In case an exception is thrown, it guarantees that everything is cleaned up.

As an example, we have a little program here

that we can call in different ways.

This is the first time we use arguments passed manually.

This allows us, for example,

to pass different arguments

or even no arguments at all,

at the moment we execute this Inverse program.

The way this is done is simply to pass a string array

which contains the arguments when we call this program

which we will name Inverse.

Here, we have a try bloc that will try to read the different arguments

Args here is an array of strings.

args[0] is the first element of this array of strings

Thus it is the first argument passed to the program when we execute it,

as I explained earlier.

We will try to read an integer in this first argument.

Then, we will divide by b.

Then, we display 100 times the inverse of this number <i>c</i>

that we have just calculated.

If the first argument that we receive is not an integer,

this expression will throw an exception of type NumberFormatException

and so this will cause us to jump to the catch bloc

corresponding to this type of exception.

We will indicate, for example, "An integer is required!".

If however we manage to read an integer from this first argument

then we pass here, we do this calculation where we risk a division by 0.

If b equals 0, this division will indeed

throw an ArithmeticException.

and we will jump to this bloc that reacts

to exceptions of type ArithmeticException

If we divide by 0, we will display that the result goes to infinity.

Then, whatever happens, whether we have an exception here,

or an exception there,

or nothing at all in this exception-aware bloc,

we will execute this mandatory segment.

We will execute the finally bloc linked to this try bloc.

Let's look at all this in detail

on different ways of calling this program.

If for example we call our program with 4.1 as an argument,

which is of type double, then

here, we will not succeed in reading an integer.

We jump here, we display "Il faut un nombre entier!" (TN: means "An integer is required!")

Since we arrive at the end of the catch bloc, we go on to the finally bloc.

Here, we write "passage obligé" (TN: means "mandatory passage") and we end the program.

On the other hand, if we passed an integer but that it is worth 0,

then we do manage to read an integer, so we continue;

here, we divide by 0, which results in an ArithmeticException

that is thrown and intercepted by this catch bloc.

So we display that the result goes to infinity.

Then we continue, as always, with the finally bloc

which indicates that we have a mandatory passage

Third case: we call our program and pass it an argument

which is a non-null integer.

At that point, we do succeed in reading an integer.

We continue. We complete the division with no problem.

So we can display that 100 times its inverse is 25.

In this case, we also finish by passing by the finally

which is executed in any case since we are in a try bloc.

Here, at the end of the execution of this try bloc,

we will continue by executing the finally bloc

and displaying that we have a mandatory passage.

To finish, here is a last example.

We pass no argument, and so the following happens:

we will want to read an integer in the first element of the array A

But it so happens that there were no arguments passed,

so this array is empty

There isn't even an element at index 0.

We have an out-of-bounds index

and so an exception will be thrown,

which is the ArrayIndexOutOfBounds exception.

So this exception will be thrown,

but as you can see,

before that, we will have passed by the finally.

Indeed, here we are in the try bloc

and as we will exit it here by throwing an exception;

this exception is not caught by any of the catch statements

However, we pass by the finally bloc.

We always pass by the finally bloc associated to a try bloc.

So we display this, before continuing with this exception

which is not caught and hence ends the program's execution

with a message meaning that the exception was not caught

followed by the call trace

at the place where this exception was thrown.

So you can see that regardless of the execution sequence

of the try bloc, we always pass by the finally bloc.

In this case here, such a finally is not very useful.

But if we had allocated ressources,

or opened files in this try bloc,

we could guarantee, by closing these resources,

by freeing these resources in the finally bloc,

we would guarantee that regardless of the execution sequence of this try bloc,

the finally bloc will correctly free the resources.

This is typically what a finally bloc is used for.

This concludes the episode on exception syntax in Java.

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

© 2018 Coursera Inc. Tous droits réservés.

Télécharger dans l'App Store

Disponible sur Google Play