C Programming Language :: Exception Handling


	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 - Hide quoted text - Walter Roberson wrote: > 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. 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. - Hide quoted text - Walter Roberson wrote: > 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(). 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