Re: Why leave the error handling to the caller?

CBFalconer said:

Richard Heathfield wrote:

... snip ...

Well, since I wasn't in on their discussion I obviously can't argue
that they did, or that they did not, carefully consider any of the
above. What I can argue is that a library function has no business
taking the decision of whether to continue or to terminate out of
the hands of the application programmer. Since xmalloc does take
that decision out of the hands of the programmer, I wouldn't want
it in any program I ever wrote. Student programming, through and
through.

Nonsense. It is entirely up to the programmer whether to call
xmalloc or malloc.

Yes, of course it is, and I didn't say otherwise. But not calling
xmalloc may, in this case, mean not calling a library function whose
functionality you really really need and whose source code you haven't
got and you only know it calls xmalloc because it shows up on the
backtrace when you try to work out why the thing keeps dumping core (if
indeed it does dump core - which it might not if the stupid thing is
calling exit rather than abort).

Frankly, I'm sick to the back teeth of Linux applications dropping dead
in the middle of a session. They are far more prone to it than Windows
applications, and I'm convinced it's because of this "do what I want or
I'll die in your face" attitude that prevails in the Linux community.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
.

Relevant Pages

  • Re: Why leave the error handling to the caller?
    ... snip ... ... since I wasn't in on their discussion I obviously can't argue ... the hands of the application programmer. ... Since xmalloc does take ...
    (comp.lang.c)
  • Re: Problem with sp_tables_rowset
    ... your connectivity API may be calling this procedure to get metadata about the database--this is what this system stored procedure is actually for; or your code is calling the procedure directly for some reason--afaik this proc is undocumented and it's not a good idea to rely on undocumented features in your own code ... Is this code that your programmer developed, or a program that you purchased? ... "Expert SQL Server 2008 Encryption" ...
    (microsoft.public.sqlserver.programming)
  • Re: time to get rid of unsigned?
    ... > If a programmer is stupid enough to write code like that, ... > be allowed to shoot him/herself in the foot, we should all pitch in to buy ... > expression before calling the function. ...
    (comp.lang.cpp)
  • Re: strongForth is alive!
    ... Its been simplified for the Programmer. ... There's less to think about in NewForth. ... calling is in marketing. ...
    (comp.lang.forth)
  • Re: The Case Against RosAsm (#6)
    ... > course) calling into your own code? ... > Being a professional programmer doesn't say anything about quality. ... > have a clue (not suggesting that this is the case with you as I don't know ...
    (alt.lang.asm)