Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

C Programming Language

Exception Handling


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.

In article <1180957125.491801.235@w5g2000hsg.googlegroups.com>,

Speed  <lostandha@gmail.com> wrote:
>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

On 4 Jun., 18:38, Speed <lostandha@gmail.com> wrote:

> 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.

Speed wrote:
> 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[#|++]?

--
"It's just the beginning we've seen"            - Colosseum, /Tomorrow's Blues/

Hewlett-Packard Limited registered office:                Cain Road, Bracknell,
registered no: 690597 England                                    Berks RG12 1HN

Speed wrote:
> 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.

Speed wrote:
> 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.

--
Tor <torust [at] online [dot] no>

In article <QrGdnYCJX91CEfnbRVnz@telenor.com>,
Tor Rustad  <tor_rus@hotmail.com> wrote:

>Speed wrote:
>> 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.

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".
--
  If you lie to the compiler, it will get its revenge. -- Henry Spencer

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

> Speed wrote:

<snip>

>> 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.

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.
--
Flash Gordon
In article <f424vd$jj@canopus.cc.umanitoba.ca>,

Walter Roberson <rober@ibd.nrc-cnrc.gc.ca> wrote:
>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

--
Dave Vandervies                             dj3va@csclub.uwaterloo.ca
Suggestions for changes to make the installer more pretty without adding
functionality or security will be met with stony silence (if you are
lucky).                    --Clever Monkey in comp.unix.bsd.openbsd.misc

In article <f426d5$qk@rumours.uwaterloo.ca>,

Dave Vandervies <dj3va@csclub.uwaterloo.ca> wrote:
>In article <f424vd$jj@canopus.cc.umanitoba.ca>,
>Walter Roberson <rober@ibd.nrc-cnrc.gc.ca> wrote:
>>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)

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.
--
  Prototypes are supertypes of their clones.           -- maplesoft

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.

--
Tor <torust [at] online [dot] no>

In article <dM-dnX-FROn9lfjbRVnz@telenor.com>,
Tor Rustad  <tor_rus@hotmail.com> wrote:

>Walter Roberson wrote:
>> 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.

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 :(
--
Programming is what happens while you're busy making other plans.

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.

>> 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.

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.

--
Tor <torust [at] online [dot] no>

llothar wrote:
> Speed <lostandha@gmail.com> wrote:

>> 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 ?

> 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.

On the contrary, it is not recommended because it is designed to
lock you into Microsoft systems, thus violently reducing
portability.

--
 <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
 <http://www.securityfocus.com/columnists/423>
 <http://www.aaxnet.com/editor/edit043.html>
 <http://kadaitcha.cx/vista/dogsbreakfast/index.html>
                        cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc