[snips]
No idea, ask the developers of that buggy application. Failed fopen() is
not an exceptional condition. Failed malloc() is. Or we are using
different vocabularies.
Apparently so. To me, they are both error conditions, to be handled
appropriately - by the caller. Neither is exceptional.
Then you are just really good. Because it's enormously more typing.
if ( ( file = fopen(...) ) == NULL ) {}
if ( ( ptr = malloc(...) ) == NULL ) {}
Yeah, enormously more, indeed.
And
more than that, it's more design questions too: "what do I do in this
situation, which I can't even possibly test?"
Can't test? Why can't you test an allocation failure? I do it all the
time. It's pretty trivial, actually, if you're using a language which
includes constructs such as if ( condition ) action. You know, like,
say, C.
All this apart from real
problems you have to solve. Yes, *real*. No, g_malloc() aborting an
application is not a real problem. Not for a regular desktop
application.
Except that at least one person *here*, in a comparatively small
community, has reported application crashes *precisely* due to this.
I wish I knew where this notion of "Hey, it's just an application, feel
free to kill it because it's 3:00, or the sky is blue, or whatever other
random event has occurred" has come from. I've been cranking apps for
most of 30 years now, and I have *never* found it acceptable for an
application to simply terminate, unless there is absolutely no other
possible option.
Except you don't open files twenty times in a row in every function in
your application. Memory is quite a different kind of resource.
Different in how you use it, you know.
Different how? Files or memory, each needs to be requested before use,
each can fail on request, each needs to have the request failure dealt
with. If the request is successful, the resource is used then disposed
of by appropriate means.
In terms *relevant to the topic*, there is no difference at all.
Request, cope with possible request failure, use, dispose.
So you click Save button then click Close. The application failed to
process Save click because it failed to allocate memory for the event
structure to put into the event queue, but then it successfully handled
Close because at the same time yet another document was closed and some
memory returned to the malloc pool.
That strikes me as a design flaw in the application. If the user
requested "save and close" and the save failed, what the hell are you
doing processing the close, instead of dealing with the error?
This would be particularly bad since the failure to save was *not*
because a file couldn't be written to, but because a menu event couldn't
be put in a message queue. If you must process the close, at least have
the decency to save the data, possibly in a scratch file which can be
recovered next time around.
Yes, certainly, at some point the options run out. If you can't allocate
space for a message on the queue, you probably also can't allocate
resources for a warning dialog. If you can't create a scratch file *and*
you can't allocate resources for the warning, there may be little you can
do but abort.
That, however, does not excuse the whole notion of "Hey, first thing we
tried failed, so let's just abort."
All allocations are checked. It's what you do when they fail is
different. If malloc(12) failed, then you are screwed because all your
code wants memory.
No, you're not screwed. You have a possible failure condition to deal
with, one which might be an expected condition, one which might not be,
and in either case, there are many possible resolutions to the problem.
No memory => application isn't working.
Or application isn't working optimally. Or _this part_ of the
application isn't working _now_, so try again in five minutes. Or...