Why do some code bases don't use exceptions?

peter koch wrote:
> On 1 Dec., 07:05, "dragan" <spambus...@prodigy.net> wrote:

>> Of
>> course, and ironically, the C++ mechanism is derived directly from
>> C's setjmp/longjmp. Whereas programmers once used to evaluate and
>> choose between alternative mechanisms, C++ not only recommends ONE,
>> but "dumbs-down" programmers (read: makes for dangerous programmers,
>> not makes for cheap project labor. Think about it).
>
> No. longjmp/setjmp is not related to exceptions.

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.

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

"dragan" <spambuster@prodigy.net> spake the secret code
<_koSm.35491$kY2.22472@newsfe01.iad> thusly:

>> No. longjmp/setjmp is not related to exceptions.
>
>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.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

"Richard" <legalize+jeeves@mail.xmission.com> wrote in message
news:hfh4n0$30u$1@news.xmission.com...
> [Please do not mail me a copy of your followup]
>
> "dragan" <spambuster@prodigy.net> spake the secret code
> <_koSm.35491$kY2.22472@newsfe01.iad> thusly:
>
>>> No. longjmp/setjmp is not related to exceptions.
>>
>>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).

On 8 Dec., 22:15, "dragan" <spambus...@prodigy.net> wrote:
> "Richard" <legalize+jee...@mail.xmission.com> wrote in message

[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

peter koch wrote:
> On 8 Dec., 22:15, "dragan" <spambus...@prodigy.net> wrote:
>> "Richard" <legalize+jee...@mail.xmission.com> wrote in message
>
> [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.

On Dec 9, 1:44*am, "dragan" <spambus...@prodigy.net> wrote:
> peter koch wrote:
> > On 8 Dec., 22:15, "dragan" <spambus...@prodigy.net> wrote:
> >> "Richard" <legalize+jee...@mail.xmission.com> wrote in message
>
> > [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.

Joshua Maurice wrote:
> On Dec 9, 1:44 am, "dragan" <spambus...@prodigy.net> wrote:
>> peter koch wrote:
>>> On 8 Dec., 22:15, "dragan" <spambus...@prodigy.net> wrote:
>>>> "Richard" <legalize+jee...@mail.xmission.com> wrote in message
>>
>>> [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.

> 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" <spambuster@prodigy.net> wrote in
news:gOKTm.18454$y%5.5032@newsfe03.iad:

> Joshua Maurice wrote:
>> On Dec 9, 1:44 am, "dragan" <spambus...@prodigy.net> wrote:
>>> peter koch wrote:
....
>>>> 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.

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.

Paavo

Paavo Helde wrote:
> "dragan" <spambuster@prodigy.net> wrote in
> news:gOKTm.18454$y%5.5032@newsfe03.iad:
>
>> Joshua Maurice wrote:
>>> On Dec 9, 1:44 am, "dragan" <spambus...@prodigy.net> wrote:
>>>> peter koch wrote:
> ...
>>>>> 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.
>
> 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.

On 25 Nov, 16:28, legalize+jee...@mail.xmission.com (Richard) wrote:
> peter koch <peter.koch.lar...@gmail.com> spake the secret code
> <99e979fd-651c-4a27-a72a-d3eab8bd9...@e27g2000yqd.googlegroups.com> thusly:

[why exceptions?]

> >int func(parm p,std::string &result)
> >{
> > * *std::string s;
> > * *int error;
>
> > * *result = func_1(parm,s);
> > * *if (error != OK)
> > * *{
> > * * * *return error;
> > * *}
> > * *error = func_2(s);
> > * *if (error != OK)
> > * *{
> > * * * *return error;
> > * *}
> > * *result = s;
> > * *return OK;
> >}
>
> >instead of the much simpler
>
> >std::string func(parm)
> >{
> > * *return func_2(func_1(parm));
> >}
>
> 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!


> - inline handling as above (hard to read code)
>
> - map HRESULTs to exceptions and handle them at the appropriate
> * boundaries (throwing a C++ exception is undefined when implementing
> * a COM object, so you have to catch and bubble out HRESULTs)
>
> The latter is the approach I have been teaching for almost 10+ years
> now and it dramatically simplifies writing and understanding such
> code.