UNIX Socket FAQ

A forum for questions and answers about network programming on Linux and all other Unix-like systems

You are not logged in.

  • Index
  • » C
  • » Exception handling in unix based C

#1 2007-08-20 08:32 AM

arun.tayal
Member
Registered: 2007-07-16
Posts: 10

Re: Exception handling in unix based C

Offline

#2 2007-08-20 09:49 AM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,239

Re: Exception handling in unix based C

That's because as far as I know, MS handles all C as C++.

If you want to use exceptions, then just use C++. Or rather, keep the code C and C++ compatible (except for the exceptions) and compile it with a C++ compiler. Or use Objective C.

C is defined by a standard, and there are some common extensions, but exceptions aren't one of them. So C with exceptions is something messed up between C++ and C.

Offline

#3 2007-08-20 11:39 AM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,839
Website

Re: Exception handling in unix based C

Offline

#4 2007-08-20 12:56 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,239

Re: Exception handling in unix based C

Exceptions have in theory a few advantages that I see:

1) It can save checks because instead something complicated is done when it goes wrong, so less has to be done when all goes right.

2) Error checking can be grouped.

3) Because error checking is explicit the compiler knows about it and can move the catch block to a separate out of line text block. Assuming catch statements are the slow path, this could improve cache and TLB-hit behaviour because more useful code is tighter together.

Saving one check in the caller might not be significant, in which case it was all for nothing. Which it probably is, thanks to branch prediction and whatnot.

The second point is appreciated by the lazy ones who resent error checking in general and don't see the point of it anyway. In practise this isn't possible very often because cleaning up the mess if something goes wrong is actually the hard part that isn't improved with exceptions at all (more like a nightmare when throwing in objects and destructors).

The third might be true, but if it is done at all, it could also decrease performance if a few try blocks are executed often.

In practise exceptions are just ugly and awkward to use more often than not, if only for the syntax. Mixing it with return value checking code makes little sense in the first place, because then there are two error handling systems used, which is only counter-productive.

Offline

#5 2007-08-20 07:34 PM

jfriesne
Administrator
From: California
Registered: 2005-07-06
Posts: 348
Website

Re: Exception handling in unix based C

Last time I checked (which admittedly was years ago), the deal-killer for exceptions in C++ was that the C++ compiler could not (or at least did not) give you any warnings or errors about possible uncaught exceptions in your code.

That meant that if you wanted to make sure your program wouldn't crash when there was an error, then for every call to a 3rd-party function foo(), you would need to check to see what exceptions foo() might throw, AND what exceptions might be thrown by any functions that foo() might call internally, AND what exceptions those sub-calls might throw, and so-on until you reached the leaves of the call-tree.  This meant that making an airtight C++ program using exceptions required the programmer to run an exponential-time code-verification algorithm in his head... and of course if you don't have access to all the source code for all the libraries you are using, then it's nearly impossible to guarantee that your program won't crash at runtime with an unhandled exception.

Contrast that to Java, where exceptions are nice and usable, because the compiler will error out if you try to call a method that might throw an exception and don't either handle the exception yourself or declare in your method header that you may pass that exception type up to the caller.

Is the above still the case for C++, or has the language and/or the compilers improved to the point where they can effectively do the checking for you, as in Java?

-Jeremy

Offline

#6 2007-08-20 07:42 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,839
Website

Re: Exception handling in unix based C

Offline

#7 2007-08-21 03:29 AM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,239

Re: Exception handling in unix based C

Years ago when I last used C++, and I never used exceptions in C++, so I don't know, but doesn't C++ have a catch all exception handler, or do you need to explicitly specify which exception should be caugth? If so, that would be horribly unusable.

I was more thinking about saving the if check by doing the sigsetjump-wannabe stuff (as storing an at compiletime known jump address is slightly simpler than doing an if-check on the return value). But your point about unhandled exceptions is very valid. The compiler can implement the kludge more efficient than doing sigsetjump stuff manually, but the idea is the same.

If you write such wrapper function then the error checking is only moved to that function, not avoided. But yeah, the practical advantage of grouping is near zero anyway.

Point 3 was a sudden idea I got, and really the only good one I could think of. A significant part of code can be error handling, and often it also has the bloaty printf stuff, so getting it out of the way might be great. Or not. Then again, the same could be done by the compiler for C code. At least for system calls and false integer, or NULL pointer if-blocks with perror or printf in them (especially fprintf to stderr). Then again, splitting functions up in such a drastical way might not be easy or always possible.

Offline

#8 2007-08-25 07:26 AM

mlampkin
Administrator
From: Sol 3
Registered: 2002-06-12
Posts: 911
Website

Re: Exception handling in unix based C

First yes...

C++ has the catch(...) syntax for indicating 'catch all / catch all remaining'...  in fact - any language ( imho ) that uses exceptions should be required to have a catch all ( and all those I know of do ) - whether its the C++ abstract '...' style or a common object hierarchy model ( e.g. Java ) where all exceptions are required to derive from a known super parent...

As for ( using C++ as an example ) not knowing what exception a specific method / function throws... C++ DOES allow you to specify that on a per method basis... it does NOT enforce required wrappers on every function declaring an exception but looking at a header file for a class using such methods fully warns any user / programmer...

Considering potential unwinding to unknown points in the stack due to unexpected errors...

Hmm...

Well using explicit exception inclusion / docs as mentioned in the prior paragraph helps but isn't a 100% cure... for process based programs ( no threads ) I handle this ( again - C++ as example ) by ALWAYS wrapping the  core calls in main with a catch( ... ) so I can spit out informative messages prior to exiting... for multi-threaded code I do the same thing but also add in thread cleanup ( forced call destructors etc. if required ) and debug wrappers... and btw - I will ALWAYS wrap any dll / external method calls with exception catch all wrappers... ALWAYS... its just common sense..

On the Java comment...

Thats kinda funny if you look at things like Hibernate etc. and convos on their forums... they have moved to the 'throw an exception but don't tell the user - just doc it'... this means you can end up with the equivalent of C++ exceptions with the 'unwind to unknown point' if someone forgets to either document a function can throw a specific exception or someone forgets to catch the exception(s) a function can throw...

Darn - all this typing and still didn't say everything I wanted... not to mention I haven't answered the initial question...  so to backtrack... all I have to say is:

"You can't get there from here"

Lol... :P



Michael


"The only difference between me and a madman is that I'm not mad."

Salvador Dali (1904-1989)

Offline

#9 2007-08-27 03:41 AM

jfriesne
Administrator
From: California
Registered: 2005-07-06
Posts: 348
Website

Re: Exception handling in unix based C

Offline

#10 2007-08-27 05:28 PM

mlampkin
Administrator
From: Sol 3
Registered: 2002-06-12
Posts: 911
Website

Re: Exception handling in unix based C

Java does not require RuntimeException(s) or classes inheriting from it to be declared or explicitly caught... as the premise is that a runtime error means the process has a ( high ) probability of being in an unknown state and the proper course of action is ( normally ) to terminate quickly...

Anyway - so what they are doing is declaring ALL of their exceptions to inherit RuntimeException...


Michael


"The only difference between me and a madman is that I'm not mad."

Salvador Dali (1904-1989)

Offline

  • Index
  • » C
  • » Exception handling in unix based C

Board footer

Powered by FluxBB