On Fri, Feb 07, 2003 at 05:54:38PM +0200, Oleg Goldshmidt wrote:

> Interesting topic. Maybe more suitable for hackers-il, as
> non-Linux-specific?

Maybe we need programming-il? 

> and __LINE__ (and if you only care about gcc than you can also use
> __FUNCTION__) then the trace is easy to follow.

__func__ is standard in C99, IIRC. Not supported in older gcc's,
though. 

> .. If you are really adventurous and *really* consistent about naming
> stuff you can in principle squeeze it into a macro call like
> 
>       VERIFY(foo(bar),rc,CLEAN_UP);
> 
> but I think that would be too clever for your own good, and trades
> readability for danger.

I use this style ONLY in testing code, where special handling is
required for almost every functions that fails. In regular code, it's
misleading and prone to error. Also, be very wary of

assert(foo(bar) == rc); 

The entire expression will only be compiled in for debug mode. Unless
you never plan to have your code called in non-debug mode, this is a
time bomb waiting to happen. 

> Finally, moving away from C to C++ and the likes, I intuitively
> dislike exceptions. I generally feel somewhat uncomfortable about
> them, because of their non-locality. It seems to me that it is much
> easier to forget to catch something or forget that something deep down
> the stack could throw an exception, compared to the explicit return
> code. This, however, may be completely baseless and misguided.

Java fixes this, FSVO "fix", by adding the exception specification
(throws...) to the function's signature. C++ does this as well, except
that the default is "throws anything", IIRC, in order to remain
compatible with C. 

Exceptions (and their primitive origins, setjmp/longjmp) are useful
when you write a parser or any other input driven engine, and you want
to handle all errors deep down in parsing in one place. Returning
errors from 5 levels of funtions is cumbersome and error prone (enough
for one caller to forget to check the callee's return value and take
appropriate action). 

> Another thing for general purpose library writers: never, under any
> circumstances, abort! Always percolate return codes to the

Amen!

HIH indeed, 
Muli. 
-- 
Muli Ben-Yehuda
http://www.mulix.org
http://syscalltrack.sf.net


--------------------------------------------------------------------------
Haifa Linux Club Mailing List (http://www.haifux.org)
To unsub send an empty message to [EMAIL PROTECTED]


Reply via email to