Ada Programming/Error handling
From Wikibooks, the open-content textbooks collection
Contents |
[edit] Error handling techniques
This chapter describes various error handling techniques. First the technique is described, then its use is shown with an example function and a call to that function. We use the √ function which should report an error condition when called with a negative parameter.
[edit] Return code
procedure Error_Handling_1 is function Square_Root (X : in Float) return Float is use Ada.Numerics.Elementary_Functions; begin if (X < 0.0) then return -1.0; else return Sqrt (X); end if; end Square_Root; begin C := Square_Root (A ** 2 + B ** 2); if C < 0.0 then T_IO.Put ("C cannot be calculated!"); else T_IO.Put ("C is "); F_IO.Put (Item => C, Fore => F_IO.Default_Fore, Aft => F_IO.Default_Aft, Exp => F_IO.Default_Exp); end if; return; end Error_Handling_1;
Our example make use of the fact that all valid return values for √ are positive and therefore -1 can be used as an error indicator. However this technique won't work when all possible return values are valid and no return value is available as error indicator.
[edit] Error (success) indicator parameter
An error condition is returned via additional out parameter. Traditionally the indicator is either a boolean with "true = success" or an enumeration with the first element being "Ok" and other elements indicating various error conditions.
procedure Square_Root (Y : out Float; X : in Float; Success : out Boolean) is use Ada.Numerics.Elementary_Functions; begin if (X < 0.0) then Y := 0.0; Success := False; else Y := Sqrt (X); Success := True; end if; return; end Square_Root;
begin Square_Root (Y => C, X => A ** 2 + B ** 2, Success => Success); if Success then T_IO.Put ("C is "); F_IO.Put (Item => C); else T_IO.Put ("C cannot be calculated!"); end if; return; end Error_Handling_2;
One restriction for Ada is that functions can not have out parameters. This restriction has been done to make code safe by not having functions with side effects. So for our example we had to use a procedure instead.
This technique does not look very nice in mathematical calculations.
[edit] Global variable
An error condition is stored inside a global variable. This variable is then read directly or indirectly via a function.
procedure Error_Handling_3 is Float_Error : Boolean; function Square_Root (X : in Float) return Float is use Ada.Numerics.Elementary_Functions; begin if (X < 0.0) then Float_Error := True; return 0.0; else return Sqrt (X); end if; end Square_Root; begin Float_Error := False; C := Square_Root (X => A ** 2 + B ** 2); if Float_Error then T_IO.Put ("C cannot be calculated!"); else T_IO.Put ("C is "); F_IO.Put (Item => C, Fore => F_IO.Default_Fore, Aft => F_IO.Default_Aft, Exp => F_IO.Default_Exp); end if; return; end Error_Handling_3;
As you can see from the source the problematic part of this technique is choosing the place at which the flag is reset. You could either have the callee or the caller do that.
Also this technique is not suitable for multithreading.
[edit] Exceptions
The programming language supports some form of error handling. This ranges from the classic ON ERROR GOTO ... from early Basic dialects to the try ... catch exceptions handling from modern object oriented languages.
The idea is always the same: you register some part of your program as error handler to be called whenever an error happens. Modern designs allow you to define more than one handler to handle different types of errors separately.
Once an error occurs the execution jumps to the error handler and continues there.
procedure Error_Handling_4 is Float_Error : exception; function Square_Root (X : in Float) return Float is use Ada.Numerics.Elementary_Functions; begin if (X < 0.0) then raise Float_Error; else return Sqrt (X); end if; end Square_Root; begin
begin C := Square_Root (A ** 2 + B ** 2); T_IO.Put ("C is "); F_IO.Put (Item => C, Fore => F_IO.Default_Fore, Aft => F_IO.Default_Aft, Exp => F_IO.Default_Exp); exception when Constraint_Error => T_IO.Put ("C cannot be calculated!"); end; return; end Error_Handling_4;
The great strength of exceptions handling is that it can block several operations within one exception handler. This eases up the burden of error handling since not every function or procedure call needs to be checked independently for successful execution.
[edit] Design by Contract
In Design by Contract (DbC) functions must be called with the correct parameters. This is the caller's part of the contract. If the types of actual arguments match the types of formal arguments, and if the actual arguments have values that make the function's preconditions True, then the subprogram gets a chance to fulfill its postcondition. Otherwise an error condition occurs. Now you might wonder how that is going to work. Let's look at the example first:
procedure Error_Handling_5 is subtype Square_Root_Type is Float range 0.0 .. Float'Last; function Square_Root (X : in Square_Root_Type) return Square_Root_Type is use Ada.Numerics.Elementary_Functions; begin return Sqrt (X); end Square_Root; begin C := Square_Root (A ** 2 + B ** 2); T_IO.Put ("C is "); F_IO.Put (Item => C, Fore => F_IO.Default_Fore, Aft => F_IO.Default_Aft, Exp => F_IO.Default_Exp); return; end Error_Handling_5;
As you see the function demands a precondition of X >= 0 - that is the function can only be called when X ≥ 0. In return the function promises as postcondition that the return value is also ≥ 0.
In a full DbC approach, the postcondition will state a relation that fully describes the value that results when running the function, something like result ≥ 0 and X = result * result. This postcondition is √'s part of the contract. The use of assertions, annotations, or a language's type system for expressing the precondition X >= 0 exhibits two important aspects of Design by Contract:
- There can be ways for the compiler, or analysis tool, to help check the contracts. (Here for example, this is the case when
X ≥ 0follows from X's type, and √'s argument when called is of the same type, hence also ≥ 0.) - The precondition can be mechanically checked before the function is called.
The 1st aspect adds to safety: No programmer is perfect. Each part of the contract that needs to be checked by the programmers themselves has a high probability for mistakes.
The 2nd aspect is important for optimization — when the contract can be checked at compile time, no runtime check is needed. You might not have noticed but if you think about it: A2 + B2 is never negative, provided the exponentiation operator and the addition operator work in the usual way.
We have made 5 nice error handling examples for a piece of code which never fails. And this is the great opportunity for controlling some runtime aspects of DbC: You can now safely turn checks off, and the code optimizer can omit the actual range checks.
DbC languages distinguish themselves on how they act in the face of a contract breach:
- True DbC programming languages combine DbC with exception handling — raising an exception when a contract breach is detected at runtime, and providing the means to restart the failing routine or block in a known good state.
- Static analysis tools check all contracts at analysis time and demand that the code written in such a way that no contract can ever be breached at runtime.
