Exception Handling

[Speed]

Hi,

I was wondering if there is any way to catch exceptions without
knowing in advance what errors may occur.

What I mean to say is that is it possible to use try {} on a bunch of
lines and catch ANY exception that might have occurred within those
few lines without the program crashing first ?

Thanks a ton,
Speed.

 

[Richard Tobin]

I was wondering if there is any way to catch exceptions without
knowing in advance what errors may occur.

What I mean to say is that is it possible to use try {} on a bunch of
lines and catch ANY exception that might have occurred within those
few lines without the program crashing first ?

A good start would be to use a language other than C...

-- Richard

 

[llothar]

Hi,

I was wondering if there is any way to catch exceptions without
knowing in advance what errors may occur.

What I mean to say is that is it possible to use try {} on a bunch of
lines and catch ANY exception that might have occurred within those
few lines without the program crashing first ?

Thanks a ton,
Speed.

Exceptions are C++, this is a C newsgroup.

The Exception is Microsoft SEH which is a recommended ABI for all C
compilers
that work on the windows plattform.

 

[Chris Dollin]

I was wondering if there is any way to catch exceptions without
knowing in advance what errors may occur.

I think you're in the wrong newsgroup: C doesn't have "exceptions".

Did you perhaps mean to be posting to comp.lang.c[#|++]?

 

[Guillaume]

I was wondering if there is any way to catch exceptions without
knowing in advance what errors may occur.

As others have said already, C doesn't really know about exceptions.

What I mean to say is that is it possible to use try {} on a bunch of
lines and catch ANY exception that might have occurred within those
few lines without the program crashing first ?

As a side note, I find this way of programming very bad practice and
quite disturbing. But that's just me.

 

[Flash Gordon]

Guillaume wrote, On 04/06/07 18:37:

Speed wrote:


As a side note, I find this way of programming very bad practice and
quite disturbing. But that's just me.

An outer level catch all errors and give the user a sane looking error
report (Error 42 in fred, please contact the Buggy SW Company for
assistence) can be helpful. Of course, this is after having tried to
explicitly handle all possible errors earlier.

 

[Tor Rustad]

Hi,

I was wondering if there is any way to catch exceptions without
knowing in advance what errors may occur.
Yes

What I mean to say is that is it possible to use try {} on a bunch of
lines and catch ANY exception that might have occurred within those
few lines without the program crashing first ?

In C, we use setjmp()/longjmp(), not C++ try {}.

You can longjmp() to where you want, on the conditions you define.

 

[Walter Roberson]

Speed wrote:

In C, we use setjmp()/longjmp(), not C++ try {}.

You can longjmp() to where you want, on the conditions you define.

Tor, I think you had better expand a bit, since the only C89
reference to exceptions is that they can happen and that the
behaviour is undefined if they do. C's setjmp() / longjmp() happen
completely until specific program control: they do not offer
any "If something goes wrong, fall through/over/up to this bit of code"
facility.

C does define a small number of signals, and signal handlers,
and defines that longjmp() may be used from within a signal
handler (but doesn't promise it works from within a nested signal
handler), but C signals are not exceptions. The only three
C89 signals that come close are SIGFPE, SIGILL, and SIGSEGV,
none of which a system is required to generate except when
explicitly requested via raise(). And if you have a SIGILL or
SIGSEGV, your program is likely in a dangerously inconsistant
state and you probably shouldn't be doing very much more before
terminating the program. To my mind, these limited and unpromised
functionality falls considerably below the standard requested by
the OP, "to catch ANY exception that might have occured within
those few lines without the program crashing first".

 

[Dave Vandervies]

C does define a small number of signals, and signal handlers,
and defines that longjmp() may be used from within a signal
handler (but doesn't promise it works from within a nested signal
handler),

longjmp may be used from within a signal handler ONLY if that signal
handler was invoked as a result of the program calling raise().
(N867 7.14.1.1#5)


dave

 

[Walter Roberson]

longjmp may be used from within a signal handler ONLY if that signal
handler was invoked as a result of the program calling raise().
(N867 7.14.1.1#5)

Interesting, that isn't in C89. C89 says,

4.6.2.1 The longjmp Function
[...]
As it bypasses the usual function call and return mechanisms,
the longjump function shall execute correctly in contexts of
interrupts, signals, and any of their associated functions.
However, if the longjump function is invoked from a nested signal
handler (that is, from a function invoked as a result of a signal
raised during the handling of another signal), the behavior is
undefined.

I have to read that as permitting longjmp() from within a non-nested
signal handler, at least in C89.

 

[Tor Rustad]

Tor, I think you had better expand a bit, since the only C89
reference to exceptions is that they can happen and that the
behaviour is undefined if they do. C's setjmp() / longjmp() happen
completely until specific program control: they do not offer
any "If something goes wrong, fall through/over/up to this bit of code"
facility.

The point about "exceptions", is not only trapping errors on the
hardware interrupt level, you can define software exceptions as well.

When a fault happen, the idea is to go back to a well-defined state,
this can be archived from C with an user written "exception" library,
Kaz a prev regular here, did provide such an implementation in his kazlib.

C applications which use this programming model, typically avoid
malloc'ed memory, for natural reasons.

Since hardware faults (signals) are difficult to specify in a portable
way, ISO C leave that job to e.g. POSIX, while Windows provide SEH.

 

[Walter Roberson]

Walter Roberson wrote:

The point about "exceptions", is not only trapping errors on the
hardware interrupt level, you can define software exceptions as well.

When a fault happen, the idea is to go back to a well-defined state,
this can be archived from C with an user written "exception" library,
Kaz a prev regular here, did provide such an implementation in his kazlib.

I've just had a look at the kazlib code, and if I scan it properly,
the only kind of exceptions that can be caught are those thrown by
a call to the kazlib's except_throw(). That violates the OP's requirement
that *ALL* exceptions be caught, without having to know what kinds
of exceptions might be thrown (in the kazlib case, one would have
to know that the exception was thrown by kazlib-aware code.)

Since hardware faults (signals) are difficult to specify in a portable
way, ISO C leave that job to e.g. POSIX, while Windows provide SEH.

My reading of your earlier posting was that you were saying
that through use of setjmp() and longjmp(), the OP's requirement
to catch *all* exceptions could be met in standard C. Your sentance above
indicates that you must go outside standard C for important classes
of exceptions -- indeed, for the only kinds of exceptions that the OP's
code would have, it not being written to be kazlib aware and the OP
having specified that rewriting the code was not an option.

*If* the OP had not specified that the black-box code in question
could not be changed, then your reply might have been appropriate
information, but as was, as setjmp() and longjmp() cannot handle
anything that the OP asked to do, your reply seems misleading enough
to potentially have sent the OP down completely the wrong path

 

[Tor Rustad]

I've just had a look at the kazlib code, and if I scan it properly,
the only kind of exceptions that can be caught are those thrown by
a call to the kazlib's except_throw().

I was talking about software generated "exceptions" here, so no reason
to be surprised that kazlib, don't handle hardware interrupts or
software "exceptions" generated from another exception library.

My reading of your earlier posting was that you were saying
that through use of setjmp() and longjmp(), the OP's requirement
to catch *all* exceptions could be met in standard C.

I said OP could catch the "exceptions" he defined, i.e. enabled and
installed a handler for. Words like *all*, *always* etc., are for others
to use.

<off-topic>
Under the Hood

If OP had understood his own question, he would know that on a
monolithic kernel, this require access to ring 0 (kernel mode). When you
have ring-based security, like e.g. Linux and Windows NT has, exceptions
at one level may destabilize higher levels, but typically not the other
way around. Of course, if you execute your program in Ring 3, you cannot
generally have access too the *all* exceptions at lower levels, this
would break the security.

Furthermore, the old interrupt model is been replaced by level-triggered
interrupts, where the device send a continuous signal down the wire,
until the interrupt service routine explicitly dismisses the interrupt.
If being at Ring 3, of course you cannot get *all* those interrupts
forwarded to you, the interrupt service routine at Ring 0 is the BOSS.
</off-topic>


The signal handling specified in C89 was not very sound, and pretty
worthless in C99 (most signals are undefined).

In a strictly conforming program you cannot longjmp out of an
asynchronous signal handler, since the jmp_buf may be in an invalid
state when the signal occur. To fix this, the programmer need to call
setjmp(), before installing the signal handler.

According to the C experts, a s.c. program can only handle synchronous
signals (SIGFPE, SIGILL and SIGSEGV). The fun part, is that in C99,
implementations don't need to generate any real signals (except after
call to raise). So, standard C is pretty useless when dealing with
hardware interrupts.