exception from C function?

Hello everyone,


As far as I know, C function does not throw exception.

But Bjarne said in his book, section 14.8 Exception and Efficiency,

--------------------
In particular, an implementation knows that only a few standard C library functions (such as atexit() and qsort()) can throw exceptions, and it can take advantage of that fact to generate better code.
--------------------

What did he mean? C function could really throw exception? What exception -- C++ exception or structured exception?


thanks in advance,
George

atexit() and qsort() accept arguments which are functions to pointers and, from a C++ perspective, there is nothing stopping the passed functions throwing exceptions.

Structured exceptions are a Microsoft-specific thing. There is nothing stopping a compiler targeting a windows OS from doing things with structured exceptions. But that is unrelated to Bjarne's comments.

Bjarne was referring to the fact that, as specified, most standard C functions have no reason to throw exceptions and do not call any function that might throw exceptions. This means that, even though standard C functions have no exception specifications (which, from a C++ perspective, means they can throw ANY exception) a C++ compiler can still take advantage of the fact they won't throw exceptions.

Thanks grumpy,


1. If C library function qsort() takes a C++ function as callback parameter, and the C++ callback function throws exception, how could the C library function qsort() handls a C++ exception?

2. If there are exceptions in the C++ callback function, and the C++ callback function catches the exception by itself, and never throws it again -- but returns error code to C function qsort() since C function can not handle C++ exception. If this is the case, I think it is not what Bjarne's point, since in this situation, there is no exception thrown from qsort() C library function.

Any comments?

Quote:

---

Originally Posted by grumpy

atexit() and qsort() accept arguments which are functions to pointers and, from a C++ perspective, there is nothing stopping the passed functions throwing exceptions.

Structured exceptions are a Microsoft-specific thing. There is nothing stopping a compiler targeting a windows OS from doing things with structured exceptions. But that is unrelated to Bjarne's comments.

Bjarne was referring to the fact that, as specified, most standard C functions have no reason to throw exceptions and do not call any function that might throw exceptions. This means that, even though standard C functions have no exception specifications (which, from a C++ perspective, means they can throw ANY exception) a C++ compiler can still take advantage of the fact they won't throw exceptions.

---

regards,
George

Well, perhaps, as you say, the qsort can throw an exception in that the C++ callback function it calls can throw an exception. Therefore you should take into mind that while a C function itself may never throw an exception, if it callbacks to a C++ function, the function can throw an exception because the execution is inside or beyond the qsort function. So you should keep in mind that a few C function could throw an exception (if not handled by the C++ callback function).

Thanks Elysia,


I am interested in how C code could keep the status elegant (example, no resource leak and no crash) when it calls a C++ function and the C++ function throws an exception. Since C has no approach to detect whether a C++ exception is thrown, even it has no cencept of what an exception is, how C code could make the status elegant looks mysterious to me... :-)

It is appreciated if you could give more description or recommend some learning resource (to save your time). :-)

Quote:

---

Originally Posted by Elysia

Well, perhaps, as you say, the qsort can throw an exception in that the C++ callback function it calls can throw an exception. Therefore you should take into mind that while a C function itself may never throw an exception, if it callbacks to a C++ function, the function can throw an exception because the execution is inside or beyond the qsort function. So you should keep in mind that a few C function could throw an exception (if not handled by the C++ callback function).

---

regards,
George

Quote:

---

Originally Posted by George2

I am interested in how C code could keep the status elegant (example, no resource leak and no crash) when it calls a C++ function and the C++ function throws an exception. Since C has no approach to detect whether a C++ exception is thrown, even it has no cencept of what an exception is, how C code could make the status elegant looks mysterious to me... :-)

---

From what I see, it can't. C wasn't designed for C++ in mind, so if the C++ function throws anything, the C function is screwed if it needs to clean up anything but stack variables.

Hi Elysia,


Sorry for my bad English. :-)

I do not understand how to translate "screwed" into an elegant and form term in C++ or C world. Could you express your point in some other statements please?

Quote:

---

Originally Posted by Elysia

From what I see, it can't. C wasn't designed for C++ in mind, so if the C++ function throws anything, the C function is screwed if it needs to clean up anything but stack variables.

---

regards,
George

You know what happens when an exception is thrown and caught outside the function. If the exception is caught in your C++ code outside qsort for example. The function never has a chance to clean up because the compiler will simply jump to your catch block without executing code in the C function, so it can't clean up. If it only uses stack variables, it will be fine, but not if it does something else.

Thanks Elysia,


Could I understand your point in the following way?

when there is exception in C++ callback code called from C code qsort(), runtime will looks for the handler of the exception and since C qsort() has no exception handler, it will jump to the higher address of the stack (higher than qsort()), maybe the called of the qsort() to seek for exception handlers.

So, for local variables in C qsort(), it is ok during stack unwinding, but for other resources, there may be leak.

My understanding correct?

Quote:

---

Originally Posted by Elysia

You know what happens when an exception is thrown and caught outside the function. If the exception is caught in your C++ code outside qsort for example. The function never has a chance to clean up because the compiler will simply jump to your catch block without executing code in the C function, so it can't clean up. If it only uses stack variables, it will be fine, but not if it does something else.

---

regards,
George

Yes.

Thanks Elysia,


You are so patient and knowable. My question is answered. :-)

Quote:

---

Originally Posted by Elysia

Yes.

---

regards,
George

Unfortunately, Elysia isn't quite right.

Code compiled with a C compiler doesn't know about exceptions. It isn't prepared for exception. There absolutely no telling what will happen if you let an exception fall out of a C++ callback called from a C function. The situation is not covered by any standard: not C++, because it can't dictate terms to C code, and not C, because it isn't aware of exceptions.

This means that the situation is undefined behaviour. It depends on how the exception handling mechanism works, and how the C implementation uses the stack. Perhaps the exception will simply fall through the C code, without cleaning up resources. Perhaps the stack unwinding will get confused and crash. Perhaps the C implementation has an extension that allows the code to clean up in the face of exceptions (perhaps SEH __finally works, for example). Perhaps the stack unwinding will get very confused and not find an exception handler even though it's there (could happen with table-based handling mechanisms) or find a handler that's totally inappropriate (could happen with stack-based handling mechanism in the face of longjmps).

The actual rule is simple: catch all C++ exceptions at the end of a callback and use the callback's error reporting mechanism (typically a return code) to report the error. The callback doesn't have such a mechanism? (qsort's callback for example) Then there probably shouldn't be any errors. (How hard can comparing two objects be?)

Quote:

---

Originally Posted by CornedBee

Code compiled with a C compiler doesn't know about exceptions.

---

This is completely true. It's probably worth noting, however, that Bjarne's comments were in the context of a compiler (or, more accurately, the developer of the compiler) being aware of requirements associated with C++. For example, if the C standard library is compiled from source with a C++ compiler.

Quote:

---

Originally Posted by CornedBee

The actual rule is simple: catch all C++ exceptions at the end of a callback and use the callback's error reporting mechanism (typically a return code) to report the error. The callback doesn't have such a mechanism? (qsort's callback for example) Then there probably shouldn't be any errors. (How hard can comparing two objects be?)

---

This could probably be used to support a position - in a future version of the C++ standard, for example - that callbacks passed to qsort() yield undefined behaviour if they throw an exception. The C standard need specify nothing, as no standard-compliant C code can throw an exception anyway.

I suspect a similar argument might also be valid for atexit() callbacks. After all, in what circumstances would someone want to throw an exception in the process of exiting from a program?

At least I nailed one thing right. I should have known it was undefined. Oh well.

On a side note, Stroustrup is wrong about atexit(): since it only registers handlers and doesn't call them, it can't throw. The function that might throw is exit().

Quote:

---

On a side note, Stroustrup is wrong about atexit(): since it only registers handlers and doesn't call them, it can't throw. The function that might throw is exit().

---

Have you considered sending him an email to make the correction in an errata and/or future edition?

Hmm, perhaps I should. But I should check the errata first. Maybe it's already there.

Edit: OK, the errata don't list anything. But I noticed that my 15th print is already behind the latest version, the 16th print.

George, which print do you have? (It's on the very bottom of the legal info page.)

Hi CornedBee,

Quote:

---

Originally Posted by CornedBee

The actual rule is simple: catch all C++ exceptions at the end of a callback and use the callback's error reporting mechanism (typically a return code) to report the error. The callback doesn't have such a mechanism? (qsort's callback for example) Then there probably shouldn't be any errors. (How hard can comparing two objects be?)

---

How could you do this if we are not allowed to modify the code of the callback function -- supposing it is from some 3rd party code? :-)

I think the issue mentioned by Bjarne is common nowadays, and you know (1) invoking qsort is common and (2) compare function is common to throw exception, and from your analysis, undefined behavior is so often. :-)


regards,
George

I agree CornedBee -- aftre reading MSDN document about atexit()!


I suggest you send him an email to let him correct his in next version. :-)

Quote:

---

Originally Posted by CornedBee

On a side note, Stroustrup is wrong about atexit(): since it only registers handlers and doesn't call them, it can't throw. The function that might throw is exit().

---

regards,
George

Hi CornedBee,


What do you mean print? The "Show Printable Version" at the bottom of the page?

Quote:

---

Originally Posted by CornedBee

Hmm, perhaps I should. But I should check the errata first. Maybe it's already there.

Edit: OK, the errata don't list anything. But I noticed that my 15th print is already behind the latest version, the 16th print.

George, which print do you have? (It's on the very bottom of the legal info page.)

---

regards,
George

For heaven's sake, learn to multiquote!

1) I'd write a wrapper for the 3rd party function that catches all exceptions.
2) Invoking qsort in C++ code shouldn't be common. std::sort is way better.
3) A compare function should not commonly throw exceptions.
4) No! Presumably, since you're quoting the book a lot, you have it, right? The book is reprinted whenever the copies run out, so there's the first print, the second print, and so on. Each new print has some minor corrections incorporated. My copy is the 15th print, but the newest is the 16th. I just want to know if you have this newest print, because then your quote would indicate that the problem hasn't been fixed.

Thanks CornedBee,


1.

Quote:

---

Originally Posted by CornedBee

2) Invoking qsort in C++ code shouldn't be common. std::sort is way better.

---

Why std::sort is faster than qsort?

2.

Quote:

---

Originally Posted by CornedBee

4) No! Presumably, since you're quoting the book a lot, you have it, right? The book is reprinted whenever the copies run out, so there's the first print, the second print, and so on. Each new print has some minor corrections incorporated. My copy is the 15th print, but the newest is the 16th. I just want to know if you have this newest print, because then your quote would indicate that the problem hasn't been fixed.

---

I am using The C++ Programming Language Special Edition 4th print -- pretty old. :-)


regards,
George

Yeah, but the issue is that atexit() is the means by which an exception can be made to occur when a program exits (by registering a function that throws).

No, the issue is that the compiler can make assumptions about exceptions being thrown if it knows which calls might throw exceptions. And any C function that doesn't call a C++ callback cannot throw exceptions. This includes atexit(), because although a callback is passed to it, it doesn't call it.

qsort is a C function, compiled into object code as it is. The callback is called through a function pointer.
sort is a C++ function template, compiled into object code whenever instantiated. The callback can be a function object, allowing inlining of the comparison, thus greatly speeding up the execution.

Thanks CornedBee,


1. What means "compiled into object code whenever instantiated"?

2. Why (1) is faster than function callback implemented by function pointer?

Quote:

---

Originally Posted by CornedBee

qsort is a C function, compiled into object code as it is. The callback is called through a function pointer.
sort is a C++ function template, compiled into object code whenever instantiated. The callback can be a function object, allowing inlining of the comparison, thus greatly speeding up the execution.

---

regards,
George

Quote:

---

Originally Posted by George2

1. What means "compiled into object code whenever instantiated"?

---

You don't know how templates works?
Because of their template-specific nature that they can use any type, the compiler only generates code when a call to the template function is made. You could save size, for one thing.

Quote:

---

2. Why (1) is faster than function callback implemented by function pointer?

---

Inline! Hello?

Thanks Elysia,


I agree with your below points. But if I understand correctly, generating only the type needed is used to save footprint to that no need to generate all possible types...

But how could it improve performance?

Quote:

---

Originally Posted by Elysia

You don't know how templates works?
Because of their template-specific nature that they can use any type, the compiler only generates code when a call to the template function is made. You could save size, for one thing.


Inline! Hello?

---

regards,
George

Quote:

---

Originally Posted by George2

But how could it improve performance?

---

How about avoiding function calls + overhead?

Quote:

---

Originally Posted by George2

Thanks Elysia,


I agree with your below points. But if I understand correctly, generating only the type needed is used to save footprint to that no need to generate all possible types...

But how could it improve performance?

---

By inlining the compare operation - the templated sort function just uses the < operator, so if it's an integer compare, it will just do that. If it's an inlinable operator< in the class object, then the compiler can inline it.

--
Mats

Thanks Elysia,

1.

You mean the performance of template function invocation is because there is additional stack operation push/pop parameters, for example?

If true, I do not think it is a special point which template function brings to us, all function call has such so-called "performance degration". :-)

Have I understood your correctly?

2.

qsort() is a inline function?

Quote:

---

Originally Posted by Elysia

How about avoiding function calls + overhead?

---

regards,
George

Hi Mats,


I little confused even if I agree with you. Looks like we are talking about template function will degrade performance compared with pure C implementation of qsort(), but you are talking template function could improve performance by inline some code like compare for POD types?

Quote:

---

Originally Posted by matsp

By inlining the compare operation - the templated sort function just uses the < operator, so if it's an integer compare, it will just do that. If it's an inlinable operator< in the class object, then the compiler can inline it.

--
Mats

---

regards,
George

Calling a function is always overhead compared to just doing the same work "here". The amount of overhead is depending on the amount of work in the function. Since qsort() may do A LOT of calls to the compare function, and comparing two data-items is USUALLY trivial, the overhead can be quite noticeable.

qsort itself may be inlined, but the comparison will ALWAYS be called through a function pointer.

--
Mats

Quote:

---

Originally Posted by George2

Hi Mats,


I little confused even if I agree with you. Looks like we are talking about template function will degrade performance compared with pure C implementation of qsort(), but you are talking template function could improve performance by inline some code like compare for POD types?




regards,
George

---

Template functions will normally be faster than qsort - that is the whole point of the last 7 or so posts.

--
Mats

Quote:

---

Originally Posted by George2

Hi Mats,

I little confused even if I agree with you. Looks like we are talking about template function will degrade performance compared with pure C implementation of qsort(), but you are talking template function could improve performance by inline some code like compare for POD types?

regards,
George

---

A template function will never degrade performance just because it's a template function. It can increase the size of the executable, but that's all.

Thanks Mats,


Let me recap your point in one sentence from the several posts. Your point is, because template function uses inline technique (e.g. inline compare function), it could be faster than qsort(), right?

Quote:

---

Originally Posted by matsp

Template functions will normally be faster than qsort - that is the whole point of the last 7 or so posts.

--
Mats

---

regards,
George

Quote:

---

Originally Posted by George2

Let me recap your point in one sentence from the several posts. Your point is, because template function uses inline technique (e.g. inline compare function), it could be faster than qsort(), right?

---

Correction: can be inlined. It's up to the compiler in the end whether or not it inlines it.

Thanks Elysia,


Your supplemental information is useful.

After discussing with you and have some self-study, the original point of this question still makes me confused -- but not as much as before, there are mainly two points about throwing exception from C++ into C caller code, and such code is not uncommon since a part of STL uses C implementation CRT.

1. Undefined behavior since C know nothing about C++ exception;

2. Defined behavior, and object on C stack will be released but other resources are not. C++ exception is pased through C code into higher memory address to look for exception handler.

Which option do you agree?

Quote:

---

Originally Posted by Elysia

Correction: can be inlined. It's up to the compiler in the end whether or not it inlines it.

---

regards,
George

1. Undefined.
Note that 2) may still happen, because it's undefined. Anything could happen. Don't rely on it, however.

Thanks for clarification, Elysia!


But I think there are lots of code nowadays invoking C function like qsort and provide throwable C++ callback code, agree? :-)

Quote:

---

Originally Posted by Elysia

1. Undefined.

---

regards,
George

Haven't used qsort, so dunno.
Just make sure to catch those exceptions in the callback code,

Thanks for your advice, Elysia!

Quote:

---

Originally Posted by Elysia

Haven't used qsort, so dunno.
Just make sure to catch those exceptions in the callback code,

---

regards,
George

Quote:

---

Originally Posted by George2

Thanks for clarification, Elysia!


But I think there are lots of code nowadays invoking C function like qsort and provide throwable C++ callback code, agree? :-)




regards,
George

---

I doubt that more than 0.01% of the code calling qsort uses code that MAY throw - why would you ever throw in a function that essentially does the same as "operator>"? It is conceivable to come up with a function that DOES throw an exception, but it would be bad practice, and what are the circumstances where you expect this to be the case?

Comparing two existing objects should not throw an exception!

--
Mats

Thanks Mats,


Beyond and comparison operator, do you think there are any other possibilities to throw in callback provided to qsort()?

Quote:

---

Originally Posted by matsp

I doubt that more than 0.01% of the code calling qsort uses code that MAY throw - why would you ever throw in a function that essentially does the same as "operator>"? It is conceivable to come up with a function that DOES throw an exception, but it would be bad practice, and what are the circumstances where you expect this to be the case?

Comparing two existing objects should not throw an exception!

--
Mats

---

regards,
George

What crazy thing could the callback do that it would throw?

The callback from qsort should only compare the input parameters and return "equal, greater or lesser" - why don't you spend a couple of hours implementing a qsort on an object, to see how it works?

--
Mats

Hi CornedBee,


Why callback can not throw exception from general programming and design perspective? Does it anti some patterns?

Quote:

---

Originally Posted by CornedBee

What crazy thing could the callback do that it would throw?

---

regards,
George

Like I said earlier, it's technically possible to construct such a thing. It is also technically possible to build a Television with all wires un-insulated, exposing tens of kilovolts to anyone getting near it. Neither is very desirable or necessary in any way.

If you want to continue discussing this matter, perhaps you can come up with a working example of using qsort() where the compare callback is actually doing something where it throws an exception for a valid reason.

--
Mats

Sorry for the inconvenience because of my bad expression, Mats!


Well... Change my question in another way, do you think it is anti pattern to let callback function to throw exception? (it is a general question, not regarding to qsort)

Quote:

---

Originally Posted by matsp

Like I said earlier, it's technically possible to construct such a thing. It is also technically possible to build a Television with all wires un-insulated, exposing tens of kilovolts to anyone getting near it. Neither is very desirable or necessary in any way.

If you want to continue discussing this matter, perhaps you can come up with a working example of using qsort() where the compare callback is actually doing something where it throws an exception for a valid reason.

--
Mats

---

regards,
George

No, not as long as it catches the exception. But the point was, for what reason would such a function throw an exception? There's very few feasible scenarios.

Thanks Elysia!


"it catches the exception" -- I think you mean C++ callback to a C function. Not for a general case of C++ callback to a C++ function. Right?

Quote:

---

Originally Posted by Elysia

No, not as long as it catches the exception. But the point was, for what reason would such a function throw an exception? There's very few feasible scenarios.

---

regards,
George

Of course. If it's C++ to C++ it's perfectly fine to throw an exception and not catch it inside the callback since the behavior this is defined.

As discussed earlier, you should not call C++ code from C where the C++ code throws (and doesn't catch) - it is undefined behaviour - if it happens to work on one system, it's not guaranteed to happen in another system.

Is that clear enough?

--
Mats

Thanks Elysia and Mats,


My question is answered.

Quote:

---

Originally Posted by matsp

As discussed earlier, you should not call C++ code from C where the C++ code throws (and doesn't catch) - it is undefined behaviour - if it happens to work on one system, it's not guaranteed to happen in another system.

Is that clear enough?

--
Mats

---

regards,
George