On Wednesday, 25 February 2015 at 16:39:38 UTC, Manu wrote:
This is precisely my complaint though. In a production
environment
where there are 10's, 100's of people working concurrently, it
is
absolutely unworkable that code can be crashing for random
reasons
that I don't care about all the time.
I've experienced before these noisy crashes relating to things
that I
don't care about at all. It just interrupts my work, and also
whoever
else it is that I have to involve to address the problem before
I can
continue.
I see what the problem can be. My feeling is that it is in part a
workplace/codebase problem. Bugs that prevent other people from
working aren't usually high on the roadmap. This also happen with
assertions, and we have to disable them to do work then ; though
assertions create no debate.
If the alternative is ignoring error codes, I'm not sure it's
better. Anything could happen and then the database must be
cleaned up.
That is a real cost in time and money. I find that situation to
be
absolutely unacceptable. I'll take the possibility that an
ignored
error code may not result in a hard-crash every time.
True eg. you can ignore every OpenGL error it's kind of hardened.
Right, but as above, this is an expense quantifiable in time and
dollars that I just can't find within me to balance by this
reasoning.
To be fair, this cost has to be balanced with the cost of not
finding a defect before sending it to the customer.
I also prefer my crashes to occur at the point of failure.
Exceptions
tend to hide the problem in my experience.
I would just put a breakpoint on the offending throw. THen it's
no different.
I find it so ridiculously hard to debug exception laden code. I
have
no idea how you're meant to do it, it's really hard to find the
source
of the problem!
I've seen this and this is true with things that need to retry
something periodically with a giant try/catch.
try/catch at the wrong levels to "recover" too much things can
also make it harder. Some (most?) things should really fail hard
rather than resist errors.
I think gamedev is more of an exception since "continue anyway"
might be a successful strategy in some capacity. Games are
supposed to be "finished" at release which is something customers
thankfully don't ask of most software.
Only way I know is to use break-on-throw, which never works in
exception laden code since exception-happy code typically throw
for
common error cases which happen all the time too.
What I do is break-on-uncatched. Break-on-throw is moreoften than
not hopelessly noisy like you said.
But I only deal with mostly reproducible bugs.
Opening files is a very infrequent operation, and one of the
poster
child examples of where you would always check the error
return. I'm
not even slightly upset by checking the return value from fopen.
But how happy are you to bubble up the error condition up to call
stack?
I'm of mixed opinion on that, seeing error code _feels_ nice and
we can say to ourselves "I'm treating the error carefully". Much
like we can say to ourselves "I'm carefully managing memory" when
we manage memory manually. Somehow I like pedestrian work that
really feels like work.
But that doesn't mean we do it efficiently or even in the right
way, just that we _think_ it's done right.
What matter in composite operations is whether all of them
succeeded or not.
Example: if the sequence of operations A-B-C failed while
doing B, you are
interested by the fact A-B-C has failed but not really that B
failed
specifically.
Not necessarily true. You often want to report what went wrong,
not
just that "it didn't work".
Fortunately exceptions allows to bring up any information about
what went wrong.
We often see on the Internet that "errors are best dealed with
where they happen".
I could not disagree more.
Where "fopen" fails, I have no context to know I'm here because I
was trying to save the game.
Error codes force to bubble up the error to be able to say
"saving the game has failed", and then since you have used error
codes without error strings you cannot even say "saving the game
has failed because fopen has failed to open <filename>".
Now instead of just bubbling up error codes I must bubble up
error messages too (I've done it). Great!
Errors-should-be-dealed-with-where-they-happen is a complete
fallacy.
I don't see exceptions are any different in this way. I see
internal
exceptions bleed to much higher levels where they've totally
lost
context all the time.
In my experience this is often due to sub-systems saving the ass
of others by ignoring errors in the first place instead of either
crashing of rebooting the faulty sub-system.
I'm not sure quite what you're saying here, but I agree with
Walter.
In case of hard logic error, the sane thing to do is crash (ie,
assert), not throw...
assert throw Error for this purpose.
Performance inhibition is a factor in considering that I've
never used
exceptions, but it's certainly not the decisive reason.
And it's a valid concern. Some program parts also seldom need
exceptions since mostly dealing with memory and few I/O.
