By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,732 Members | 1,388 Online
Bytes IT Community
+ Ask a Question
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
Share this Question
Share on Google+
9 Replies


P: n/a
Ian
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" <no***@nowhere.com> 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 <ob**********@elsewhere.net> 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 <setjmp.h>. 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 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


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" <ob**********@elsewhere.net> 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 <ob**********@elsewhere.net> 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.