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.
Gestion des exceptions : introduction
Loading...
來自 École Polytechnique Fédérale de Lausanne 的課程
Introduction à la programmation orientée objet (en Java)
148 個評分
École Polytechnique Fédérale de Lausanne
148 個評分
從本節課中
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.
與講師見面
Jamila SamDr
School of Computer and Communication Sciences
Jean-Cédric ChappelierDr.
School of Computer and Communication Sciences
The exception handling is an important chapter for basic programming.
It renders our programs
sturdier and more resistant
towards abnormal or error situations.
Exception handling is not per se a concept
of object-oriented programming. However, its implementation resorts
to the use of these concepts.
The goal of this episode is to present the fundamental aspects
of exception handling in Java.
In this chapter, we will discuss how to handle errors
or abnormal situations in a program.
We will see that exception handling let us anticipate
the errors and abnormal situations.
Thus, we will be able to react appropriately.
Let us begin by illustrating the usefulness of exception handling
through a simple example.
We wish to code a function "f" which calculates the inverse of a given number.
We wish for this function to handle the case where the entered value is 0
as an abnormal situation, an error situation.
We also wonder how to handle
the error itself.
Here is our first attempt :
We can have it so that, in case the entered value is 0,
we return a value chosen in advance.
To mimic the fact that this result would be close to infinity, we could decide
-- in an arbitrary way -- to return
the biggest "double" possible.
In Java, there are other predefined values to mimic the infinity (such as "infinity").
However, this is not our point here.
Unfortunately, this way to proceed is not satisdactory at all.
Firstly, this does not let the user know
that his input has resulted in an abnormal situation for the function "f"
since "x" is 0.
Here, the user is never warned of this fact.
Also, the returned result is necessarily inexact.
The use of this "f" resorts to an arbitrary convention
which is not necessarily known by other programmers.
Here, the choice of the return value is such a convention.
To overcome this lack of information that the user of the function "f" is facing
when we are divide by 0,
we could imagine to have our function "f" print an error message
whenever the entered value is 0. We would have our function print
that there is an error situation : a division by 0.
However, this does not solve all the problems
of the previous version. Indeed, we still have no idea
what we should return in an error situation.
This solution can also face criticism since it triggers so-called
"edge effects".
This means that the function "f", which is only supposed to return
the inverse of a number is now generating printings
in the terminal; this is not its usual task!
Indeed, let us imagine we are using "f" within a graphical program.
In this case, we do not want for an abnormal situation
to be reported by a message on the terminal
but rather by the opening of an alert window, for example.
Finally, even though the function "f"
is the juncture of the program where the error is detected,
it might not be the place to handle
this situation properly.
Indeed, a division by 0
could be harmful enough
to require the program to be stopped.
Also, it is possible for a division by 0 to be handled
according to the context of utilization.
This means that it is the juncture of the program calling the function "f",
informed of the context, that could give the appropriate measures
in case there is a division by 0.
A last option would be to rewrite the function "f"
so that it rather returns an error code
indicating if the division has been computed correctly.
Then, it will return the result of the division only in a normal situation,
when there is no error with the parameter.
This way to proceed is better than the previous ones.
Indeed, this way, the function calling "f"
is able to decide what to do in case of error.
The function "f" itself should not be the one taking this decision;
it should simply inform its caller upon the execution.
Then, the caller will decide what to do in case of error.
Unfortunately, this way to proceed renders the use of the function
much less intuitive.
Instead of writing something simple
which would mean
let us store into "y" the result of the inversion of "x"
computed by the method "f", we should resort to
more complex instructions.
First, we should know that "f" returns an error code
and that the normal utilization result is stored in the second parameter.
This is clearly less intuitive
than this way of writing things.
Moreover, when a method calls another which then calls another
and so on, each call could potentially result in an error code.
In this case, we must then handle the combinations
of all these error codes. Obviously, this quickly becomes unpleasant.
Now, we wish to get our hands on a mechanism
which would let us report an error situation
without triggering any of these undesired edge effects.
We also wish to possess a mechanism letting us handle the error
at another place than the one where it is detected.
This should all be done while keeping utilization flexibility,
an intuitive intuition of the different functionalities
we wish to have in our programs.
Execption handling meets all our needs.
At the place where the error is detected, we will be able to trigger an "exception".
This "exception" can then be handled at another place in the program.
Also, we are not compelled to explicitly integrate any error code
in the different functionalities we wish to implement.
The mechanism of exception handling works according
to the three points developped here.
Whenever an error or abnormal situation is detected
somewhere in the program,
we will warn the rest of the program by "throwing an object"
containing all the useful informations so that we can potentially handle
this error or abormal situation
elsewhere in the program.
"Throwing" or "triggering an exception" concretely means creating an object
which becomes available for the rest of the program.
This object can then be "caught", which means "used",
elsewhere in program so that we can handle this abnormal situation,
completely or partialy.
Finally, if the "thrown object" is never "caught",
it will trigger the stop of the program.
An unhandled thrown exception always triggers the stopping of the program.
Let us illustrate this with a concrete example.
Let us imagine, for example, that we have a main program
working with temperatures.
These temperatures are aquired through, for example, a meter.
These temperatures are then stored in an array. Our program's task
is to draw a graphic of the inverse of all the aquired temperatures.
Let us imagine these temperatures are aquired
through a not fully reliable meter.
Therefore, every once in a while, it could fail to measure
the temperature correctly
and would, for instance, add null values
into our temperature array.
The main program realizes its processing by calling
another function called "graphiqueInverse" (TN: means "invertPlot").
This function will iterate on all the temperatures of a provided array
and display the graph of their inverse.
This method thus resorts to another method
which calculates the inverse of a double.
The method "inverse" is absolutely not aware of its utilization context.
It does know not what to do
if the provided value is zero.
It corresponds to this value in the array.
However,
the main program knows in what context this method is called
and is therefore able to solve the problem.
For example, it could decide
that if the display of the temperatures has failed,
which means that the aquired temperatures were corrputed,
then we must recover them anew.
The idea motivating exception handling is that the part of the program
detecting an abnormal situation,
while remaining unable to treat it locally,
will report it to the rest of the program
by "throwing an exception".
The "exception" is a particular object provided to the rest of the program.
If this thrown object is not caught anywhere else in the program,
its execution will be canceled : we could not handle the error.
Obviously we can also have another part of the program,
aware of the error's context,
"catch" this object and dealing with it appropriately.
The main program will have to show that it is receptive
to the "thrown" objects, and that it can receive with them.
In this case,
it will be able to "catch" the object
and deal with it
if, of course, the object has been thrown during the execution of the receptive block.
In order to develop such a process,
we need to realize four elementary tasks.
The first is the signalment of an error.
This is what our "inverse" method was doing
when it was "throwing" an object to warn the rest of the program of this abnormal situation.
The error signalement was thus what was going on at this step of our example.
The second task is to mark the areas receptive to the errors.
This is what our main program was doing here
to indicate it is able to "catch" and deal with such an object
corresponding to an abnormal sitatuion.
To each area receptive to errors, abnormal situations,
we need to provide a tool to actually deal with these errors.
This means "catching" the object and dealing with it.
In our example,
each receptive block has been provided
with a set of instructions able to deal with the object, catching it.
Finally, in certain cases, it can be necessary to do some cleaning
after a block receptive to errors. For example,
we could need to liberate some resources
which have been used but not properly liberated
due to an abnormal situation.
To each of these four tasks, there is a coresponding Java keyword.
In order to to report the error, we use the keyword "throw".
In order to make the areas receptive to erros, we use "try".
In order to provide the block receptive to errors
wich a handling bock, we use the keyword "catch".
And finally,
in order to make some room, we use the keyword "finally".
The detailed description on the use of these keywords
will be presented in the next episode.
To make things clear,
the program area detecting the error will "throw" the object
thanks to the reserved keyword "throw".
Later, we will see what is "thrown" exactly.
The area receptive to the throw objects
is delimited with the reserved keyword "try".
This means each block receptive to errors is indicated with this keyword.
Then, to each of these blocks,
we must associate a block able to deal with the error.
The error will be caught with the keyword "catch".
As said, we will see the precise syntax
in the following episodes.
As you have probably noticed through our little example,
the reporting of the errors thanks to the keyword "throw"
and the solving of these mistakes through the blocks "try" and "catch"
generally happen at distinct areas in the code.
Actually, this is precisely the appeal of exception handling.
In our example,
the "throw" is placed in the "inverse" method.
The blocks "try" and "catch" are placed in the main program.
In the next episodes, we will see that to each "try",
a "catch" must be associated or possibly even
several "catch" blocks.
To sum up, an exception is thus a way to report an event
requiring particular attention in the program
This event can be a severe mistake
requiring for the whole program to be stopped
or simply an unusual situation which we
will solve appropriately.
This was the case in our previous example. There, a division by zero
corresponded to an unusual situation.
Here, it does not correspond to a dramatic situation
and can be solved, for example, by retaking the measures
without having to shut down the program.
Exception handling will be a tool letting us improve
the sturdiness of our programs and will make it possible to separate the code
dedicated to error handling
from the code realizing the other processing
happening in a normal situation.
Exception handling will also let us
force an answer to particular errors.
For example, here,
with an unusual situation we need to solve appropriately.
Unlike the solution presented at the beginning of this sequence,
where we were dealing the abornoam situations
so that the methods of functions return error codes,
exception handling provides quite a few advantages.
Among the most important is that the writing will be easier,
more intuitive, more readable.
For example, our method calculating the inverse
can still be used in a very natural way.
Thus, it is not necessary
to pollute the code by adding
other parameters solely dedicated to error handling.
The propagation of the exception to higher call levels
will be done automatically.
It is thus not necessary for every intermediate call level
to deal with the error.
For example, if the exception thrown by the "inverse" method
is not caught by the calling method, named "graphiqueInverse",
the object will be automatically
thorwn to the upper call level
which will then be able to deal with it like the main program.
An error can now occur at any call level
while still being carried over to the rest of the program.
As we have just seen,
exception handling presents many an advantage
in order to solve error situations,
abnormal situations in our program.
However, the underlying mechanisms do come with a certain cost.
Thus arises a methodological rule
which will be discussed in the following episodes.
The rule is this the following:
If an error can be dealt with locally
(this means that, at a certain place, we are fully informed
on how to solve the error),
then we should immediately do it locally
without using the mechanism of exceptions.
