445,732 Members | 1,388 Online
Need help? Post your question and get tips & solutions from a community of 445,732 IT Pros & Developers. It's quick & easy.

# Implementing exceptions of C++ in C

 P: n/a Hi All, I am not sure if I should be asking this question on clc or clc++. Let me try on both. I hope that this is not too trivial for the brilliant minds over here. I know that OOP questions have been asked on clc before so it is probably OK. I am a newbie to C++. BS 3rd edition states: % The throw transfers control to a handler for exceptions .... % % ... the implementation will unwind the function call stack as needed to get % back to the context of that caller. Thus throw acts as a multilevel return. My mind is so C-ish that I totally fail to comprehend what is going on. My dumb brain has these pre-reqs. Explain the usage and idea of throw exception try catch with a C++ code and a parallel code in C. If it must involve goto's, go ahead. But the translation must be as highly parallel as possible. Furthermore, if you have some way to depict this, and supplement by "function call stack" diagrams, all the better. Thanks++, -- ,--. Bernard Klein, Berlin, Germany ,= ,-_-. =. / ,- ) ((_/)o o(\_)) \ -' -'(. .)-' -. \_/ Jul 22 '05 #1
9 Replies

 P: n/a Bernard wrote: Hi All, I am not sure if I should be asking this question on clc or clc++. Let me try on both. I hope that this is not too trivial for the brilliant minds over here. I know that OOP questions have been asked on clc before so it is probably OK. I am a newbie to C++. BS 3rd edition states: % The throw transfers control to a handler for exceptions .... % % ... the implementation will unwind the function call stack as needed to get % back to the context of that caller. Thus throw acts as a multilevel return. My mind is so C-ish that I totally fail to comprehend what is going on. My dumb brain has these pre-reqs. Explain the usage and idea of throw exception try catch with a C++ code and a parallel code in C. If it must involve goto's, go ahead. But the translation must be as highly parallel as possible. Furthermore, if you have some way to depict this, and supplement by "function call stack" diagrams, all the better. I don't think there is a clean way of replicating this in C. Otherwise we'd all be doing it! It requires run time support in C++, so you can't make a stand alone C++ app with exceptions, you have to link a run time. Also C doen't create "Objects" in the C++ sense (no concept of a destructor), so you can't destroy them as the stack is unwound. Ian Jul 22 '05 #2

 P: n/a "Ian" wrote in message I don't think there is a clean way of replicating this in C. Otherwise we'd all be doing it! It requires run time support in C++, so you can't make a stand alone C++ app with exceptions, you have to link a run time. That might be true on your platform, because exceptions require a lot of extra code which might be in a library somewhere. However there is no inherent reason why C++ program including exceptions can't be standalone exectutables. Also C doen't create "Objects" in the C++ sense (no concept of a destructor), so you can't destroy them as the stack is unwound. This is the problem. It is extremely difficult to implement exception handling in C, certainly in any form that is human-usable. Jul 22 '05 #3

 P: n/a On 2004-04-17, Bernard wrote: I am a newbie to C++. BS 3rd edition states: % The throw transfers control to a handler for exceptions .... % % ... the implementation will unwind the function call stack as needed to get % back to the context of that caller. Thus throw acts as a multilevel return. My mind is so C-ish that I totally fail to comprehend what is going on. Consider setjmp() and longjmp() from . The analogs are not perfect, but longjmp() acts as a multilevel return. My dumb brain has these pre-reqs. Explain the usage and idea of throw exception try catch with a C++ code and a parallel code in C. See: http://www.nicemice.net/cexcept/ -- James Jul 22 '05 #4

 P: n/a Thus far, all replies are useful but let me explain ... OK, if you cannot write translation of the C++ code in parallel C for whatever reason - that I will try to understand later - can you explain program flow. This is what is not clear to me. If you put some verrry simple C++ code (for learning syntax) and words or flowchart to explain program flow. I mean C books have those railroad diagrams for trivial things like sequence-selection-iteration-continue-break etc. Can we see a clear program flow for this statement? As well as a note to describe the side-effects of this stack? You gotta make lucid what is not. Not make lucid what already is simple, like sequence-selection-iteration-continue-break. I totally fail to comprehend what is going on. Explain the usage and idea of throw exception try catch with a C++ code and arrows or words to show program flow. From: http://www.nicemice.net/cexcept/ \begin{quotation} cexcept Cosmin Truta and I have developed a try/catch/throw exception-handling interface for C. It basically works the way you would expect: Try { /* Maybe a Throw statement will be executed */ /* (maybe within a deeply nested function): */ /* Throw e; */ /* If so, execution jumps to the catch clause. */ } Catch (e) { /* An exception was thrown and copied into e. */ } The interface of the latest release is fully implemented and documented in cexcept.h. \end{quotation} does have try-catch but not throw syntax. I want to first absorb the syntax and then its semantic meaning in terms of program flow. C code, requested in original post, was just a language that I knew well. Thanks++, -- ,--. Bernard Klein, Berlin, Germany ,= ,-_-. =. / ,- ) ((_/)o o(\_)) \ -' -'(. .)-' -. \_/ Jul 22 '05 #5

 P: n/a On Sat, 17 Apr 2004 07:27:40 PST in comp.lang.c++, ob**********@elsewhere.net (Bernard) wrote,Thus far, all replies are useful but let me explain ...OK, if you cannot write translation of the C++ code in parallelC for whatever reason - that I will try to understand later - canyou explain program flow. This is what is not clear to me. If youput some verrry simple C++ code (for learning syntax) and wordsor flowchart to explain Nobody can explain it to you as long as you crosspost between comp.lang.c and comp.lang.c++, because any correct answer is going to be off-topic in at least one of those groups. Jul 22 '05 #6

 P: n/a Bernard wrote: Thus far, all replies are useful but let me explain ... OK, if you cannot write translation of the C++ code in parallel C for whatever reason - that I will try to understand later - can you explain program flow. This is what is not clear to me. If you int foo1() { int bar = 1; throw bar; return 2; } int foo2() { float bar = 1.0f; throw bar; return 2; } int main() { int result = EXIT_FAILURE; try { foo1(); foo2(); result = EXIT_SUCCESS; } catch(int x) { printf("int exception caught: %d", x); } catch(...) { printf("unknown exception caught"); } return result; } OK, it works like this. main() starts as usual, and executes as usual up until it hits the "try". At that point, the compiler has noted that any exceptions thrown inside that block are handled by one of the handlers immediately following it. Then execution continues. When it gets to foo1(), foo1() throws an exception of type int. Immediately normal execution stops, and the program starts looking for the exception handler that will be responsible for handling the int exception. There is no "try" block in foo1(), so it just leaves it (cleaning up anything that needs to be cleaned up along the way) without executing the return statement and climbs back up the call stack up a step. Then it's in main(), and main *does* contain a "try" block. So it checks the handlers ("catch" statements) at the end of the try block to see if any matches. Note, it does NOT call foo2() or the next statement, it goes immediately to the handler. Because there is a handler for int, it goes there, and inside the exception, it prints "int exception caught: 1" (I hope, I don't use printf anymore). Once it gets to the end of the catch block, it skips to the end of all the exception handlers, and executes the return statement. So linearly, this is what happened: main starts: main: int result = EXIT_FAILURE; main: foo1(); foo1 starts: foo1: int bar = 1; foo1: throw bar; int exception thrown (value: 1), immediately leaves foo1 jumps to int exception handler main: sets x = 1 (from the exception) main: printf("int exception caught: %d", x); finished exception handler main: return result; main ends: Now if you comment out the throw statement in foo1, you get this instead: main starts: main: int result = EXIT_FAILURE; main: foo1(); foo1 starts: foo1: int bar = 1; foo1: return 2; foo1 ends: foo2 starts: int exception thrown (value: 1), immediately leaves foo2 looks for float exception handler, can't find it, sees a "catch-all" handler, jumps there main: printf("int exception caught: %d", x); finished exception handler main: return result; main ends: The mechanics of it are pretty complex, and that without nesting try blocks or other complexities. It's probably better to think of exceptions in terms of what they are there for. Consider the following example: vector3d shrink_vector(vector3d v, int scale_factor) { v.x /= scale_factor; v.y /= scale_factor; v.z /= scale_factor; return v; } vector3d make_unit_vector(vector3d v) { // calculates vector's length. not important, so not included int length = get_vector_length(v); return shrink_vector(v, length); } void high_level_function() { vector3d v = get_vector_somehow(); vector3d u = make_unit_vector(); printf("Your unit vector is: (%d, %d, %d)", u.x, u.y, u.z); } Now, take a look at shrink_vector(). What if the scale_factor is 0? You can't divide by zero, that would be a disaster. But what on earth is shrink_vector() supposed to do if you send it a 0? Should it silently convert it to 1? No, that makes no sense. Return vector (0, 0, 0)? No, that also makes no sense, mathematically. It could call some kind of error function, but which one? You won't be able to reuse the function easily if you have to use it with the same error function. Clearly, the best think for shrink_vector to do is pass the buck. After all, it wasn't responsible for the 0 and it couldn't fix it. So rewrite it as: vector3d shrink_vector(vector3d v, int scale_factor) { if (scale_factor == 0) { divide_by_zero_exception dbz; throw dbz; } v.x /= scale_factor; v.y /= scale_factor; v.z /= scale_factor; return v; } Now, what about make_unit_vector()? It would know if it was trying to make a zero-vector a unit vector after it finds the length, but what should it do about it? Again, you *could* put the error handling in there, but that would limit the reuse. So, do nothing. Now, high_level_function should know what to do if there is a problem. So rewrite it like this: void high_level_function() { try { vector3d v = get_vector_somehow(); vector3d u = make_unit_vector(); printf("Your unit vector is: (%d, %d, %d)", u.x, u.y, u.z); } catch (divide_by_zero_exception x) { printf("You entered a zero vector."); } // NOTE: any exceptions that high_level_function does // not need to know how to handle, get passed up to whoever // called it (eg. an out of memory exception) } So all the exception handling is in one place, and that's in a high level function that knows what to do about it. As your program gets smarter, it scales nicely. For example, suppose that in the get_vector_length() function, calculating the length turns out to cause integer overflow. No problem, just throw an integer_overflow_exception there, and add a catch block in high_level_function to handle it. I have tried to keep the examples as C-like as possible, but obviously, this is a C++ phenomenon. That opens up a whole new world of constructors and destructors, and the possiblity of using polymorphic objects as exception types (in the example above, both divide_by_zero_exception and integer_overflow_exception could derive from math_exception, then you would only need to catch that, unless you were interested in the specifics), among other things. Some aspects of exception handling can be mimed in C, but since C is not polymorphic object aware and does not know about destructors, there would be a forbidding amount of work to get the full power without introducing a whole whack of bugs (and by that I mean work not only on the side of the guy making them, I mean also work by the guy trying to use them). mark Jul 22 '05 #7

 P: n/a "Bernard" a écrit dans le message de news:d5*************@ID-300100.news.uni-berlin.de... Hi All, Hi, I am not sure if I should be asking this question on clc or clc++. Let me try on both. I hope that this is not too trivial for the brilliant minds over here. I know that OOP questions have been asked on clc before so it is probably OK. I am a newbie to C++. BS 3rd edition states: % The throw transfers control to a handler for exceptions .... % % ... the implementation will unwind the function call stack as needed to get % back to the context of that caller. Thus throw acts as a multilevel return. My mind is so C-ish that I totally fail to comprehend what is going on. My dumb brain has these pre-reqs. Explain the usage and idea of throw exception try catch with a C++ code and a parallel code in C. If it must involve goto's, go ahead. But the translation must be as highly parallel as possible. Furthermore, if you have some way to depict this, and supplement by "function call stack" diagrams, all the better. Laurent Deniau provides a basic but very nice implementation in C of C++-style exceptions with his library OOPC (Object Oriented Programming in C). It's well documented and easy to use. http://ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html Regis Thanks++, -- ,--. Bernard Klein, Berlin, Germany ,= ,-_-. =. / ,- ) ((_/)o o(\_)) \ -' -'(. .)-' -. \_/ Jul 22 '05 #8

 P: n/a On 2004-04-17, Bernard wrote: From: http://www.nicemice.net/cexcept/ \begin{quotation} cexcept Cosmin Truta and I have developed a try/catch/throw exception-handling interface for C. It basically works the way you would expect: Try { /* Maybe a Throw statement will be executed */ /* (maybe within a deeply nested function): */ /* Throw e; */ /* If so, execution jumps to the catch clause. */ } Catch (e) { /* An exception was thrown and copied into e. */ } The interface of the latest release is fully implemented and documented in cexcept.h. \end{quotation} does have try-catch but not throw syntax. I want to first absorb the syntax and then its semantic meaning in terms of program flow. C code, requested in original post, was just a language that I knew well. It doesn't seem like you tried to read the source code in the cexcept.h file. If you understand C, then read the code. If you don't understand the C code, post your C question to comp.lang.c. -- James Jul 22 '05 #9

 P: n/a James Hu wrote: .... snip ... It doesn't seem like you tried to read the source code in the cexcept.h file. If you understand C, then read the code. If you don't understand the C code, post your C question to comp.lang.c. Since people seem to refuse to cut the cross-postings out, the only thing left to do is to PLONK this thread. -- fix (vb.): 1. to paper over, obscure, hide from public view; 2. to work around, in a way that produces unintended consequences that are worse than the original problem. Usage: "Windows ME fixes many of the shortcomings of Windows 98 SE". - Hutchison Jul 22 '05 #10

### This discussion thread is closed

Replies have been disabled for this discussion.