From: david.brown@hesbynett.no
On 24/10/2025 01:31, Keith Thompson wrote:
> David Brown writes:
>> On 22/10/2025 15:56, Janis Papanagnou wrote:
> [...]
>>> switch (cmd) {
>>> case 'C': ...;
>>> case 'M': ...;
>>> default: printf ("Error: uncaught cmd '%c'\n", cmd);
>>> }
>>> It's good to take precautions and define the 'default' case. YMMV.
>>
>> That's not "taking precautions". If the "...optionally verify cmd"
>> part does a good job, then the default line is worse than useless
>> because it is code that never runs. If that part doesn't exist (since
>> it is "optional"), then the default line is not "taking precautions",
>> it is normal handling of a realistic situation.
>
> Error handling can be complicated.
>
That's a good entry for the "understatement of the week" competition!
> You're right that code that prints a message for a condition that
> should never happen (equivalently, that can only happen as a result
> of a programming error) is difficult to test. (I suppose you could
> tweak the code to introduce an error so the message is triggered,
> but that's ugly and difficult to automate.)
>
> For example, the failure of the first Ariane 5 launch involved
> an unexpected error diagnostic message being interpreted as data.
> If the error had been quietly ignored, the rocket might have survived.
>
> If a condition is really expected never to happen, something
> like gcc's _builtin_unreachable might be useful, or more portably
> an assert.
>
I like a macro that can then expand to different things according to
what I want to do such as "__builtin_unreachable()" for gcc,
"unreachable()" for C23, blank for other tools, for use with well
checked and well tested code. Alternatively it can expand to a check of
some sort, a log, a debug message, an LED indicator, or whatever during
testing, debugging, or fault-finding.
> If you want to test for a condition that should never happen, you
> need to think about how you would want to handle it. If the best
> way to handle it is to abort the application, that's easy enough.
> If it's a safety critical system, though, it might be better to
> attempt to log an error message (in a way that won't itself cause
> a problem) and try to continue running.
>
Indeed. Very often you see error handling that is done without due
thought about how the errors could occur, and what you should do about
them. I see code that obsessively checks "malloc" for zero returns,
because someone heard that you should always check the result of
"malloc". That's fair enough if you are in a situation where malloc
could fail, and when you can do something about it that is better than
ignoring it - but usually malloc cannot fail in any remotely realistic
use-case, and usually there's nothing you can do anyway that is better
than continuing until dereferencing a null pointer crashes your code.
Basically, there's no point in asking a question until you have a plan
of what to do with the answer.
> And yes, handling a condition that can actually happen (say, in the
> presence of bad input) is quite different.
>
Very much so, yes. "Edge" code - whether it is getting data from
outside, or is an API called by external code - has to sanitize its
inputs. Internal code should not be second-guessing other parts of the
same code - if you can't trust the different bits of the same project to
get things right, you have big problems that can't be solved by adding
default cases. (Where the boundaries between "internal" and "edge" code
go will obviously vary.)
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
