Why do some code bases don't use exceptions?

[Richard]

[Please do not mail me a copy of your followup]

"dragan" <[email protected]> spake the secret code

Yes, it is. It was an "advanced" EH technique in C and exceptions model that
basic behavior. That's why C++ exceptions are "derived" from that technique.

I disagree. It is the weaker of the two (setjmp/longjmp vs. C++
exceptions), not the more advanced. C++ exceptions are in no way
derived from setjmp. setjmp/longjmp is essentially a non-local goto.
It is not an exception, nor does it unwind the stack, it simply
overwrites the stack pointer.

 

[Kaz Kylheku]

[Please do not mail me a copy of your followup]

"dragan" <[email protected]> spake the secret code

Yes, it is. It was an "advanced" EH technique in C and exceptions model that
basic behavior. That's why C++ exceptions are "derived" from that technique.

I disagree. It is the weaker of the two (setjmp/longjmp vs. C++
exceptions), not the more advanced. C++ exceptions are in no way
derived from setjmp. setjmp/longjmp is essentially a non-local goto.
It is not an exception, nor does it unwind the stack, it simply
overwrites the stack pointer.

throw is also essentially a non-local goto.

Real exception handling does not unwind anything. By its very essence, an
exceptional situation must preserve all possible context, because any of it may
be necessary for resolving the situation.

Do you think that your operating system could properly handle a page fault
exception if the hardware unwound the stack before calling the handler?

Now /that/ is exception handling: load the page, wire in the TLB entry, and try
it again.

The amazing result is that you can use your disk as memory.

The amazing result in C++ exception handling is that the HTML response telling
you that the server crashed has all of its nesting properly closed, thanks to
unwinding! Yay.

 

[peter koch]

[Please do not mail me a copy of your followup]

"dragan" <[email protected]> spake the secret code
<[email protected]> thusly:

I disagree.  It is the weaker of the two (setjmp/longjmp vs. C++
exceptions), not the more advanced.  C++ exceptions are in no way
derived from setjmp.  setjmp/longjmp is essentially a non-local goto.
It is not an exception, nor does it unwind the stack, it simply
overwrites the stack pointer.

throw is also essentially a non-local goto.

Real exception handling does not unwind anything. By its very essence, an
exceptional situation must preserve all possible context, because any of it may
be necessary for resolving the situation.

This has nothing to do with exception-handling using C++ terms.

Do you think that your operating system could properly handle a page fault
exception if the hardware unwound the stack before calling the handler?

Now /that/ is exception handling: load the page, wire in the TLB entry, and try
it again.

Again: This is not C++ exception handling.

The amazing result is that you can use your disk as memory.

Yup - that is truly amazing. It must be brand new technology?

The amazing result in C++ exception handling is that the HTML response telling
you that the server crashed has all of its nesting properly closed, thanks to
unwinding! Yay.

What? Did you program that?

/Peter

 

[dragan]

[Please do not mail me a copy of your followup]

"dragan" <[email protected]> spake the secret code

Yes, it is. It was an "advanced" EH technique in C and exceptions model
that
basic behavior. That's why C++ exceptions are "derived" from that
technique.

I disagree. It is the weaker of the two

I made no assertion of the relative "strength" of setjmp/longjmp and C++
exceptions. You did not comprehend the sentence.

(setjmp/longjmp vs. C++
exceptions), not the more advanced. C++ exceptions are in no way
derived from setjmp.

I disagree. The similarity is too uncanny to not be related. As C++ was
designed to formalize and build upon existing C practices, it makes sense.

setjmp/longjmp is essentially a non-local goto.
It is not an exception, nor does it unwind the stack, it simply
overwrites the stack pointer.

No one was suggesting anything of the sort. I'll excuse your
miscomprehension of what I wrote only if English is not your primary
language. (Because I'm tired of all the childish antics in programming
forums).

 

[peter koch]

[snip]

(setjmp/longjmp vs. C++
exceptions), not the more advanced.  C++ exceptions are in no way
derived from setjmp.

I disagree. The similarity is too uncanny to not be related. As C++ was
designed to formalize and build upon existing C practices, it makes sense..

setjmp/longjmp is essentially a non-local goto.
It is not an exception, nor does it unwind the stack, it simply
overwrites the stack pointer.

No one was suggesting anything of the sort. I'll excuse your
miscomprehension of what I wrote only if English is not your primary
language. (Because I'm tired of all the childish antics in programming
forums).

I believe you told us that you had read "The Design and Evolution of C+
+" by Stroustrup. If that was the case, you'd be aware of the origin
of the C++ exception mechanism. The origin is Ada, and the belief that
a try-block executes anything similar to a setjmp or that a catch
executes anything similar to a longjmp is misleading and wrong.
Not very many would use setjmp/longjmp anywhere outside a tightly
controlled environment for error-management. I've tried doing so in a
very small project and it simply does not work: you risk ressource
leaks anywhere, meaning that you have to do a quite consuming program
analysis every time you allocate any ressource. Not only in the
function you change, but also to check if your function might call
something that might longjmp on you.

/Peter

/Peter

 

[dragan]

[snip]

(setjmp/longjmp vs. C++
exceptions), not the more advanced. C++ exceptions are in no way
derived from setjmp.

I disagree. The similarity is too uncanny to not be related. As C++
was designed to formalize and build upon existing C practices, it
makes sense.

setjmp/longjmp is essentially a non-local goto.
It is not an exception, nor does it unwind the stack, it simply
overwrites the stack pointer.

No one was suggesting anything of the sort. I'll excuse your
miscomprehension of what I wrote only if English is not your primary
language. (Because I'm tired of all the childish antics in
programming forums).

I believe you told us that you had read "The Design and Evolution of
C+ +" by Stroustrup. If that was the case, you'd be aware of the
origin of the C++ exception mechanism. The origin is Ada, and the
belief that a try-block executes anything similar to a setjmp or that
a catch executes anything similar to a longjmp is misleading and
wrong.

The pattern is the same. No one suggested that the _mechanisms_ were the
same or even alike. "Jumping across levels" is jumping across levels.

 

[Joshua Maurice]

[snip]

(setjmp/longjmp vs. C++
exceptions), not the more advanced. C++ exceptions are in no way
derived from setjmp.
I disagree. The similarity is too uncanny to not be related. As C++
was designed to formalize and build upon existing C practices, it
makes sense.
setjmp/longjmp is essentially a non-local goto.
It is not an exception, nor does it unwind the stack, it simply
overwrites the stack pointer.
No one was suggesting anything of the sort. I'll excuse your
miscomprehension of what I wrote only if English is not your primary
language. (Because I'm tired of all the childish antics in
programming forums).

I believe you told us that you had read "The Design and Evolution of
C+ +" by Stroustrup. If that was the case, you'd be aware of the
origin of the C++ exception mechanism. The origin is Ada, and the
belief that a try-block executes anything similar to a setjmp or that
a catch executes anything similar to a longjmp is misleading and
wrong.

The pattern is the same. No one suggested that the _mechanisms_ were the
same or even alike. "Jumping across levels" is jumping across levels.

They're not. You have to manually jump back and forth with longjmp,
that is at least a round trip to free resources. Exception handling is
a one way trip. That's fundamentally different. Perhaps they both
serve a similar purpose, but they "get there" in very different ways.

 

[dragan]

[snip]

(setjmp/longjmp vs. C++
exceptions), not the more advanced. C++ exceptions are in no way
derived from setjmp.

I disagree. The similarity is too uncanny to not be related. As C++
was designed to formalize and build upon existing C practices, it
makes sense.

setjmp/longjmp is essentially a non-local goto.
It is not an exception, nor does it unwind the stack, it simply
overwrites the stack pointer.

No one was suggesting anything of the sort. I'll excuse your
miscomprehension of what I wrote only if English is not your
primary language. (Because I'm tired of all the childish antics in
programming forums).

I believe you told us that you had read "The Design and Evolution of
C+ +" by Stroustrup. If that was the case, you'd be aware of the
origin of the C++ exception mechanism. The origin is Ada, and the
belief that a try-block executes anything similar to a setjmp or
that a catch executes anything similar to a longjmp is misleading
and wrong.

The pattern is the same. No one suggested that the _mechanisms_ were
the same or even alike. "Jumping across levels" is jumping across
levels.

They're not.

I didn't say 'they', I said 'the': the pattern defined as propagating across
levels as compared to propagating one activation record at a time. That is
THE key behavior of C++ exception machinery, hence the focus on that and
what I thought would have been obvious contextually given the topic (I guess
not!). Read the whole passage again and you will surely understand it as
what I reframed if you don't whittle out a portion of it and react only to
that portion.

 

[dragan]

But this is exactly what happens when an exception is thrown: each
call stack frame is processed, one at a time, and all automatic
objects destroyed properly. You have to invent something else if you
still want to argue that longjmp and exceptions are essentially the
same.

You fail to recognize that I never said anything of the sort. Stop wasting
my time thank you.

 

[Nick Keighley]

peter koch <[email protected]> spake the secret code
<99e979fd-651c-4a27-a72a-d3eab8bd9...@e27g2000yqd.googlegroups.com> thusly:

[why exceptions?]

This sort of code is profusely present in code that uses COM because
every method on a COM interface typically returns an HRESULT status
code that you should check.

it's the C way there's loads of stuff that works like that. Embedded
SQL, sockets, Win32. Every function returns an error code and you have
to check it.

Result db_update_box_title (Box_id id, const char *title)
{
Box_data data;
Db_conn connection = db_get_connection();
if (connection == NULL)
return E_CANT_CONNECT;

db_read_box (id, &data);
CHECK_DB;

strcpy (data.title, title);

db_write_box (id, &data);
CHECK_DB;
}

Where CHECK_DB did something like

if ((result = sql_error()) != SQL_OK)
return result;

this was actually a concious effort to emulate exceptions. The code
could have been far nastier!

There are three ways I've seen people deal with such error codes:
- ignore them and pretend errors never happen (bad code)

oh yes! At least they have write extra code to ignore exceptions!