1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
|
/*===
cexcept.h 2.0.1 (2008-Jul-19-Sat)
http://www.nicemice.net/cexcept/
Adam M. Costello
http://www.nicemice.net/amc/
An interface for exception-handling in ANSI C (C89 and subsequent ISO
standards), developed jointly with Cosmin Truta.
Copyright (c) 2000-2008 Adam M. Costello and Cosmin Truta.
This software may be modified only if its author and version
information is updated accurately, and may be redistributed
only if accompanied by this unaltered notice. Subject to those
restrictions, permission is granted to anyone to do anything
with this software. The copyright holders make no guarantees
regarding this software, and are not responsible for any damage
resulting from its use.
The cexcept interface is not compatible with and cannot interact
with system exceptions (like division by zero or memory segmentation
violation), compiler-generated exceptions (like C++ exceptions), or
other exception-handling interfaces.
When using this interface across multiple .c files, do not include
this header file directly. Instead, create a wrapper header file that
includes this header file and then invokes the define_exception_type
macro (see below). The .c files should then include that header file.
The interface consists of one type, one well-known name, and six macros.
define_exception_type(type_name);
This macro is used like an external declaration. It specifies
the type of object that gets copied from the exception thrower to
the exception catcher. The type_name can be any type that can be
assigned to, that is, a non-constant arithmetic type, struct, union,
or pointer. Examples:
define_exception_type(int);
enum exception { out_of_memory, bad_arguments, disk_full };
define_exception_type(enum exception);
struct exception { int code; const char *msg; };
define_exception_type(struct exception);
Because throwing an exception causes the object to be copied (not
just once, but twice), programmers may wish to consider size when
choosing the exception type.
struct exception_context;
This type may be used after the define_exception_type() macro has
been invoked. A struct exception_context must be known to both
the thrower and the catcher. It is expected that there be one
context for each thread that uses exceptions. It would certainly
be dangerous for multiple threads to access the same context.
One thread can use multiple contexts, but that is likely to be
confusing and not typically useful. The application can allocate
this structure in any way it pleases--automatic, static, or dynamic.
The application programmer should pretend not to know the structure
members, which are subject to change.
struct exception_context *the_exception_context;
The Try/Catch and Throw statements (described below) implicitly
refer to a context, using the name the_exception_context. It is
the application's responsibility to make sure that this name yields
the address of a mutable (non-constant) struct exception_context
wherever those statements are used. Subject to that constraint, the
application may declare a variable of this name anywhere it likes
(inside a function, in a parameter list, or externally), and may
use whatever storage class specifiers (static, extern, etc) or type
qualifiers (const, volatile, etc) it likes. Examples:
static struct exception_context
* const the_exception_context = &foo;
{ struct exception_context *the_exception_context = bar; ... }
int blah(struct exception_context *the_exception_context, ...);
extern struct exception_context the_exception_context[1];
The last example illustrates a trick that avoids creating a pointer
object separate from the structure object.
The name could even be a macro, for example:
struct exception_context ec_array[numthreads];
#define the_exception_context (ec_array + thread_id)
Be aware that the_exception_context is used several times by the
Try/Catch/Throw macros, so it shouldn't be expensive or have side
effects. The expansion must be a drop-in replacement for an
identifier, so it's safest to put parentheses around it.
void init_exception_context(struct exception_context *ec);
For context structures allocated statically (by an external
definition or using the "static" keyword), the implicit
initialization to all zeros is sufficient, but contexts allocated
by other means must be initialized using this macro before they
are used by a Try/Catch statement. It does no harm to initialize
a context more than once (by using this macro on a statically
allocated context, or using this macro twice on the same context),
but a context must not be re-initialized after it has been used by a
Try/Catch statement.
Try statement
Catch (expression) statement
The Try/Catch/Throw macros are capitalized in order to avoid
confusion with the C++ keywords, which have subtly different
semantics.
A Try/Catch statement has a syntax similar to an if/else statement,
except that the parenthesized expression goes after the second
keyword rather than the first. As with if/else, there are two
clauses, each of which may be a simple statement ending with a
semicolon or a brace-enclosed compound statement. But whereas
the else clause is optional, the Catch clause is required. The
expression must be a modifiable lvalue (something capable of being
assigned to) of the same type (disregarding type qualifiers) that
was passed to define_exception_type().
If a Throw that uses the same exception context as the Try/Catch is
executed within the Try clause (typically within a function called
by the Try clause), and the exception is not caught by a nested
Try/Catch statement, then a copy of the exception will be assigned
to the expression, and control will jump to the Catch clause. If no
such Throw is executed, then the assignment is not performed, and
the Catch clause is not executed.
The expression is not evaluated unless and until the exception is
caught, which is significant if it has side effects, for example:
Try foo();
Catch (p[++i].e) { ... }
IMPORTANT: Jumping into or out of a Try clause (for example via
return, break, continue, goto, longjmp) is forbidden--the compiler
will not complain, but bad things will happen at run-time. Jumping
into or out of a Catch clause is okay, and so is jumping around
inside a Try clause. In many cases where one is tempted to return
from a Try clause, it will suffice to use Throw, and then return
from the Catch clause. Another option is to set a flag variable and
use goto to jump to the end of the Try clause, then check the flag
after the Try/Catch statement.
IMPORTANT: The values of any non-volatile automatic variables
changed within the Try clause are undefined after an exception is
caught. Therefore, variables modified inside the Try block whose
values are needed later outside the Try block must either use static
storage or be declared with the "volatile" type qualifier.
Throw expression;
A Throw statement is very much like a return statement, except that
the expression is required. Whereas return jumps back to the place
where the current function was called, Throw jumps back to the Catch
clause of the innermost enclosing Try clause. The expression must
be compatible with the type passed to define_exception_type(). The
exception must be caught, otherwise the program may crash.
Slight limitation: If the expression is a comma-expression, it must
be enclosed in parentheses.
Try statement
Catch_anonymous statement
When the value of the exception is not needed, a Try/Catch statement
can use Catch_anonymous instead of Catch (expression).
Everything below this point is for the benefit of the compiler. The
application programmer should pretend not to know any of it, because it
is subject to change.
===*/
#ifndef CEXCEPT_H
#define CEXCEPT_H
#include <setjmp.h>
#define define_exception_type(etype) \
struct exception_context { \
jmp_buf *penv; \
int caught; \
volatile struct { etype etmp; } v; \
}
/* etmp must be volatile because the application might use automatic */
/* storage for the_exception_context, and etmp is modified between */
/* the calls to setjmp() and longjmp(). A wrapper struct is used to */
/* avoid warnings about a duplicate volatile qualifier in case etype */
/* already includes it. */
#define init_exception_context(ec) ((void)((ec)->penv = 0))
#define Try \
{ \
jmp_buf *exception__prev, exception__env; \
exception__prev = the_exception_context->penv; \
the_exception_context->penv = &exception__env; \
if (setjmp(exception__env) == 0) { \
do
#define exception__catch(action) \
while (the_exception_context->caught = 0, \
the_exception_context->caught); \
} \
else { \
the_exception_context->caught = 1; \
} \
the_exception_context->penv = exception__prev; \
} \
if (!the_exception_context->caught || action) { } \
else
#define Catch(e) exception__catch(((e) = the_exception_context->v.etmp, 0))
#define Catch_anonymous exception__catch(0)
/* Try ends with do, and Catch begins with while(0) and ends with */
/* else, to ensure that Try/Catch syntax is similar to if/else */
/* syntax. */
/* */
/* The 0 in while(0) is expressed as x=0,x in order to appease */
/* compilers that warn about constant expressions inside while(). */
/* Most compilers should still recognize that the condition is always */
/* false and avoid generating code for it. */
#define Throw \
for (;; longjmp(*the_exception_context->penv, 1)) \
the_exception_context->v.etmp =
#endif /* CEXCEPT_H */
|
