home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Club Amiga de Montreal - CAM
/
CAM_CD_1.iso
/
files
/
196.lha
/
Exception_v0.6
/
excption.man
< prev
next >
Wrap
Text File
|
1988-12-27
|
26KB
|
924 lines
EXCEPTION HANDLING ROUTINES
_______ _ _ Version 0.6
July 6th, 1988
Gerald T HEWES
46 Blvd Inkermann
92220 NEUILLY S/S
FRANCE
I INTRODUCTION
The purpose of this module is to provide a programmer with a set of
easy to use routines to handle error conditions. The principle of
exception handling is inspired from Ada(r) exception routines.
Exception handling helps to solve difficult error handling conditions
such as No more memory, file not open, read/write error.... Usually
because of the difficulty of handling these errors, not much action is
done to correct them. How many programmers faithfully test all their
fread or fwrite results for possible errors?
Exception may be used by any program either as a flow control or
either to capture software errors i.e 68000 exceptions and Traps.
Exception makes the usage of traps very easy from C, since no assembly
code is required.
Experienced programmers might not find anything really new about
these routines and may have already adopted ways to deal with error
handling but I feel it might help recent Amiga programmers and anybody
who is not interested in wrinting for the (n+1)th time similar
procedures.
These routines are very different from the GOMF software. You may
have as many "protected code" zones in your program as you want, and
you dispose of a mean to propagate easily errors upward if you cannot
fix the problem at a low level (usually the case for fwrites's). In
any case, no actions are taken whatsoever, control is simply passed to
your local (context wise) handling routine. Your task is not
suspended. All your handling routines are in user mode with
multitasking enabled.
- 0 -
1.2 Contents
I INTRODUCTION
II EXCEPTION HANDLING
2.1 Introduction to Exception Handling
2.1.1 Top Level
2.1.2 Resource Protection
2.2 How to Use Excption
2.2.1 ExcpGlobal
2.2.2 MAIN
2.2.3 ExcpDeclare
2.2.4 BEGIN/EXCEPTION/END
2.2.5 Variables
2.2.6 Excption Class Numbers
2.3 Important Data
III ORGANISATION
3.1 Files
3.2 Macros
IV IMPROVEMENTS
V CONCLUSION
VI BIBLIOGRAPHY
- 1 -
II EXCEPTION HANDLING
2.1 Introduction to Exception Handling
Error Management and complexe human interfaces are always a
difficult problem in a program, and no perfect solution exists.
Exception handling is one way to alleviate the problem, but does not
solve it. These techniques were originally applied on a sun
workstation for an interactive program. Port was then done on the
Amiga, with a better interface. Originally, the ideas commes from
Ada's(r) exception handling but has been slightly modified to take
into account C's differences. A first difference is the use of
Macros, these do not have the power of defined keywords in Ada. The
second major difference stems from the fact that Ada(r) protects you
from every error condition possible, while this library will only
recuperate errors which normally give birth to
"SoftWare Error/Task Held". Thus you still enjoy fireworks for fatal
errors destroying the operation of the system.
What is exactly exception programing? In gross terms, algorithms
usually describe the normal flow of operations. Unfortunately,
exceptional activities can happen and have to be treated. If nothing
is provided by the language, the programmer has to introduce many
control statements to take into account these abnormal conditions.
The programer usually ends up with a code twice the size of the
original algorithm. This has two inconvenients: the code is no longer
clear because of the overhead, and it is hard to follow the flow of a
normal program. Exception programing tries to solve this problem.
The principle is clear, write the normal code, and add at the end of
this code the code describing those exceptional events. Each part
being separate, programs get much clearer.
Lets consider a simple problem. You want to translate from
cartesian coordinates to polar coordinates. The method in the first
quadrant is theta = atan (y/x). This formula is true for x <> 0, if x
= 0, then theta = pi/2. With no exceptions this gives:
- 2 -
if (x != 0)
{
z = y/x;
theta = atan(z);
}
else
theta = pi/2;
The normal flow is lost in the if condition. Exception programing
would prefer:
ADA:
begin
z := y/x;
theta := atan(z);
exception
when NUMERIC_ERROR =>
theta = pi/2;
when others =>
PUT("UNKNOWN ERROR");
raise ERROR;
end;
This is simply translated into:
C:
BEGIN
{
z = y/x;
theta = atan(z);
}
EXCEPTION
{
switch(Eclass)
{
case ZERO_DIVIDE : theta = pi/2; break;
default : puts("UNKNOWN ERROR"); RAISE(ERROR);
}
}
END;
This may not seem remarkable on a simple example, but it can become
very handy in real life problems which usually are not coded in 6
lines.
The idea is simple. In a protected region, you describe the simple
algorithm. Automatic errors, or software detected ones can provoke an
"Exception" which will cause the program to abandon the protected
region to execute the handler region instead. Either this handler is
qualified to handle the exception and thus controls resumes after the
protected/handler block, or the handler can decide to propagate the
exception to the next handler.
This is the second advantage of Exception programing. Protected
blocks can be inscribed inside each other like russian dolls. An
exception can thus be handled, at the most convenient level, and
necessary action while "poping" out can be performed, like liberating
- 3 -
some resources allocated in the normal flow.
This is why Exception handling is very practical in riche
environments like the amiga. For example, you can isolate all the
function calls in your main Wait loop with a protection zone. If
anything happens, including an abort request, control resumes back to
your main loop where you can decide what to do. Thus your main Wait
loop can be seen as a "top level" for your program. Deep in your
code, if you get stuck, a raise to the "top level" is always
available.
Here are a few possible scenarios:
2.1.1 Top Level
forever
{
Wait();
if (EXIT) break;
BEGIN
{
switch() { Some Dangerous Functions }
}
EXCEPTION
{
switch(Eclass) { .... }
}
END
}
2.1.2 Resource Protection
In this construction, you cannot leave the area without liberating
your resource, even if the error will be handled at higher level.
Allocate-Resource
BEGIN
{
Use-Resource (Dangerous Area)
Liberate-Resource
}
EXCEPTION
{
Yell
Liberate-Resource
Propagate-Error-If-Necessary
}
END
2.2 How to Use Excption
In order to use all the exception handling routines you need to
include the following file:
#include "local:excption.h"
For examples of the use of the exception handler consult the two
- 4 -
supplied examples "essai.c" and "fact.c".
2.2.1 ExcpGlobal
This static definition is needed once in your code. It reserves a
structure needed by the handling code to operate. ExcpGlobal is
implemented as a macro.
2.2.2 MAIN
The first protected block, called throughout this document "top
level block" is of a particular form. This block does not need a
declaration statement of the form ExcpDeclare, all relevant data is
already declared in the ExcpGlobal structure. The format of the first
protected is MAIN/EXCEPTION/OUT. The form BEGIN/EXCEPTION/END cannot
be used. This is very important because the MAIN and OUT macro
perform the necessary initialization and conclusion functions.
Here is an example:
main()
{
other declarations ...
some code ...
MAIN
{
protected code ...
}
EXCEPTION
{
Exception handling code ...
}
OUT
yet more code ...
}
Note: the toplevel does not need to be in the main function.
2.2.3 ExcpDeclare
Declare an exception handling routine in the current function.
This is a macro which hides the necessary declaration of hidden
variables. As such it must be used before any program statement.
Currently only one protected zone may exist in one routine.
2.2.4 BEGIN / EXCEPTION / END
Exception handling is based on the notion of protected blocks of
statements. In the current implementation, only one block per
function is allowed. This in practice has not been an handicap and
may be changed in future releases. This limitation only stems from
the Macros used, not from any limitation by the exception handling
routines. The syntax is:
- 5 -
toto()
{
ExcpDeclare;
other declarations ...
some code ...
BEGIN
{
protected code ...
}
EXCEPTION
{
Exception handling code ...
}
END
yet more code ...
}
In the some code block, nothing is changed, so put your faithful code
in this area. No niceties are provided.
In the protected code block, you have acces to the following
functions:
RAISE(ExcpClass) : raise an error.
BLOW(ExcpClass) : raise/blow to top level handler.
Control will be transferred to the exception handling block. Your
exception will then be handled by this code. Either the exception is
propagated with a RAISE statement to upper levels, or it is handled
locally. If it is handled locally, execution will resume in the yet
more code area. If no exception occur in the protected code block,
control continues normally in the yet more code area.
These two function may also be called from any subroutines called
in the protected code block. They may not be called from another task
if a task is created in the protected code block.
A return statement is not allowed in the protected code area, and
the exit function is not recommended. Long Jumps are not recommended:
Exception handling is long jumping, stay consistent. Goto's are not
allowed to span in or out of the protected code block. All those
limitations come from the fact that you have to execute the END code
before leaving the function. The END code, disables the current
context and restores the previous (upper) one. If you want to
LongJmp, you can modify your code to use instead the propagation
mechanism.
In the handling code block you should test the exceptions and either
handle them locally, or propagate them upward. You have access to the
same functions:
- 6 -
RAISE(ExcpClass) : raise an error to the next level
BLOW(ExcpClass) : raise/blow to top level handler.
RAISE has the same operation as when employed in the protected code
block, but will transfer control to the next (upper)level handling
code, raising the error. Once raised, there is no way to resume
processing in the yet more code block.
The same restrictions apply to the handling code block as to the
protected block concerning: goto,return,exit,_exit,longjmp,...
2.2.5 Variables
The following variables are defined in the Handler routines:
Eclass : Exception class of the exception
In the exception handling zone, Eclass contains the exception
number being treated. Be sure to check this number because the system
may generate numbers that you have not planned for. For example the
system traps all 68000 errors, Eclass is then the Trap number as
defined by Motorola. This is very useful for program debugging since
the code traps bus errors which usually indicate pointer troubles.
If you do not handle the error locally, the call RAISE(Eclass) is a
must. By doing this you can correct the exception at a higher level.
2.2.6 Excption Class Numbers
All exceptions have an exception class number which serves as an
identification. Numbers from 1-65535 are reserved values which may
not be used. Under the current version words 1-1023 are reserved for
68000 related problems. Check the values defined in excption.h for
more information. This range covers 68000 exception, 68000 traps and
could cover 68000 interrupts. Range 1024-2047 are global types of
error which are also declared in exception.h. Most of these
declarations are inspired from Ada.
Range 2048-65535 are reserved for libraries. These values cannot
be used for an application.
Application must use numbers over 65536.
The programmer must take great care to avoid using the same number
for two different exception. Unfortunately, this has to be done by
hand. This is a major difference with Ada. Two, incompatible ways can
be used for allocating these exception class numbers.
The first method is to #define all your exception class numbers, in
a fashion similar to the handler itself. This is the most simple way
but has the inconvenience of being dangerous. Two exceptions might
use the same number. Coherence has to be maintained by the
programmer. This method is not recommended for large programs.
The second method is to use the allocating function
AllocException(). AllocException returns a unique exception number
starting from 65536. This automatically insures the coherence of all
part of a large program. Its inconvenient is that it requires more
code from the programmer point of view.
The current algorithm for allocation is rudimentary. You can only
- 7 -
call AllocException with an argument of -1. This means, as for many
Amiga allocating function, that you have no preference for the number
allocated. Allocation starts from 65536, and increments by one at
every call. FreeAllocation is for decoration since it does nothing.
I might consider providing better allocation mechanism in the future,
but for the moment I see no use for it.
2.3 Important Data
I add this paragraph since I do not have the appropriate
documentation. If you catch an error report it.
When a 68000 exception occurs, the Amiga OS detects it and treats
it. The Excption 68000 number is calculated and pushed down on the
SSP stack after the usual exception frame. Control is then given
back, in superuser mode, to the code pointed by task->tc_TrapCode.
When using the exception handling routines, this points to my
assembler EIExcpHandler routine.
This routine tests if the code is running on a 68000. If yes, the
SSP stack is corrected by 6+4 bytes for simple exception, and 14+4
bytes for bus or address exceptions. The +4 comes from the Long Word
pushed by the Amiga Os.
If the code is running on a 68010 or +, operations are very
different. The handler, fetches the format number at SSP+8 and
corrects the SSP by the following values:
Values in 16-bit words
Format
0 1 2 3 4 5 6 7 8 9 a b c d e f
-------------------------------------------------------------
4 4 6 0 0 0 0 0 29 10 16 46 0 0 0 0
As usual, 4 bytes have to be added to these numbers. These table
may be inaccurate since I do not have a good documentation on these
values.
After correcting the SSP stack, the handler passes in User Mode,
and calls the EIEndHandler (a C function) with the exception number
(provided by Amiga OS) as sole argument.
- 8 -
III ORGANISATION
3.1 Files
To compile programs you need to assign local: to contain
excption.lib, excption.h and boolean.h. You must have directory named
private with the excppriv.h file in it. Your programs need to include
the definition file "local:excption.h".
As of version 0.4, all routines are compiled seperately. For
Lattice users, these object modules are all joined in the excption.lib
lattice library. To compile your code all you need to do id to add
LIB local:excption.lib
to your blink command. Currently the files are organised as follows:
-excption.h : file which your code needs to include to use the
exception routines.
-boolean.h : file included by excption.h
-excption.lib : library file to use with blink.
-excption.man : this file
-excption.doc : documentation on defined functions
-EI*.c : source for defined functions
-excphand.a : assembler handling routine
-essai.* : A good example of use of exceptions
-fact : A bad example, for different reasons but instructive.
-README : text file describing the contents and the version
differences.
3.2 Macros
This is a resume of the available Macros, Variables and Functions:
BEGIN : M start of a protected block
BLOW : M give control to outmost handler
Eclass : V exception class
END : M end of handler block
ExcpAlloc : F allocate an unique exception class number
ExcpDeclare : M declare an excption block in a routine
EXCPDISABLE : M disable processor error handling
EXCPENABLE : M enable back processor handling (Default Mode)
ExcpFree : F free an allocated exception class number
ExcpGlobal : M declare a global structure needed by exception
EXCEPTION : M end of protected block, beginning of handler
MAIN : M start of outmost protected block (replaces BEGIN)
OUT : M end of outmost protected block (replaces END)
- 9 -
RAISE : M Propagate exception to inmost handler
- 10 -
IV IMPROVEMENTS
The following ideas will be investigated in further releases:
-Signaling to the User that an 68000 exception has occured. Useful
for debugging.
-Final Catch of 68000 exceptions and user notice at the top level.
-Provide a mean for the program to call a supplied function before
giving control to the local exception handling code
-Run time library version
-Stack checking before saving context
-Tracing of entrance into protected blocks in a debug version.
Discussing with some Ada compilers makers was instructive. Their
point of view was that they do not want exception handling to lose
time in normal operations. On the other hand they are willing to
consecrate a big amount of time to solve where the control has to
resume when an exception is raised. This is radically different from
my implementation with longjmps. Each BEGIN statement needs to save
the environment which is slow. When an exception is raised, restoring
the environment is not costly. Those Ada compiler makers have thus
used a completely different approach. At compile time they note where
each handler is active. When an exception occurs, the program tests
where the exception occured, and thus where to branch. It is not
necessary to save the environment at each begin. To achieve this you
need to have exception handling defined in the language, not out of
it. Which is best?
Performances:
Version 0.5 seemed to have no bugs. There are two things to
watch. Bad bugs will crash the system, because they destroy the
environment. Nothing can be done by software. The exception handler
is fairly safe since its always checks its data coherence, if an error
occurs, an exit(200) or exit(201) is performed. These two exits have
always been due to unmatched BEGIN/EXCEPTION/END statements, even in
spots far from where the program stopped. Check those if this happens
to you.
- 11 -
V CONCLUSION
Exception programming is a very powerful tool, but should be
carefully used. 68000 Exceptions should stay exceptional. Keep in
mind that an exception declaration in a routine consumes about 40
bytes in the stack. Recursive functions have to be carefully
examined. A good knowledge of LongJumping although not necessary can
help resolve all kinds of conflicts you may run into. This code can
be particularly helpful in the debugging period, but is unfortunately
incompatible with Fred Fish DBUG macros. In general, this software
does not like longjmps.
Because of its similarity with Ada(r) Exception handling,
consulting a manual on Ada, and mostly on how to use its exception
mechanism is a recommended idea.
- 12 -
VI BIBLIOGRAPHY
* [ADA 83]
REFERENCE MANUAL FOR THE ADA(r) PROGRAMMING LANGUAGE ---
ANSI/MIL-STD 1815 A
* [BEHM 86]
NOTES SUR LE TRAITEMENT DES EXCEPTIONS --- Patrick BEHM, BULL,
Louveciennes
(r) ADA is a registered trademark of the U.S. Government. Ada Joint
Program Office.
- 13 -
