Re: else ladders practice

On 10/11/2024 05:22, Janis Papanagnou wrote:

On 09.11.2024 12:06, David Brown wrote:

On 09/11/2024 07:54, Janis Papanagnou wrote:

>
Well, it's a software system design decision whether you want to
make the caller test the preconditions for every function call,
or let the callee take care of unexpected input, or both.
>

>
Well, I suppose it is their decision - they can do the right thing, or
the wrong thing, or both.
>
I believe I explained in previous posts why it is the /caller's/
responsibility to ensure pre-conditions are fulfilled, and why anything
else is simply guaranteeing extra overheads while giving you less
information for checking code correctness.  But I realise that could
have been lost in the mass of posts, so I can go through it again if you
want.

 I haven't read all the posts, or rather, I just skipped most posts;
it's too time consuming.

I should probably have skipped /writing/ the posts - it was too time consuming :-)

 Since you explicitly elaborated - thanks! - I will read this one...
 

[...]
>
(On security boundaries, system call interfaces, etc., where the caller
could be malicious or incompetent in a way that damages something other
than their own program, you have to treat all inputs as dangerous and
sanitize them, just like data from external sources.  That's a different
matter, and not the real focus here.)
>

We had always followed the convention to avoid all undefined
situations and always define every 'else' case by some sensible
behavior, at least writing a notice into a log-file, but also
to "fix" the runtime situation to be able to continue operating.
(Note, I was mainly writing server-side software where this was
especially important.)

>
You can't "fix" bugs in the caller code by writing to a log file.
Sometimes you can limit the damage, however.

 I spoke more generally of fixing situations (not only bugs).

OK.  It can certainly help with /finding/ bugs, that can then be fixed later.

 

>
If you can't trust the people writing the calling code, then that should
be the focus of your development process - find a way to be sure that
the caller code is right.  That's where you want your conventions, or to
focus code reviews, training, automatic test systems - whatever is
appropriate for your team and project.  Make sure callers pass correct
data to the function, and the function can do its job properly.

 Yes.
 

>
Sometimes it makes sense to specify functions differently, and accept a
wider input.  Maybe instead of saying "this function will return the
integer square root of numbers between 0 and 10", you say "this function
will return the integer square root if given a number between 0 and 10,
and will log a message and return -1 for other int values".  Fair enough
- now you've got a new function where it is very easy for the caller to
ensure the preconditions are satisfied.  But be very aware of the costs
- you have now destroyed the "purity" of the function, and lost the key
mathematical relation between the input and output.  (You have also made
everything much less efficient.)

 I disagree in the "much less" generalization. I also think that when
weighing performance versus safety my preferences might be different;
I'm only speaking about a "rule of thumb", not about the actual (IMO)
necessity(!) to make this decisions depending on the project context.
 

My preferences are very much weighted towards correctness, not efficiency.  That includes /knowing/ that things are correct, not just passing some tests.  And key to that is knowing facts about the code that can be used to reason about it.  If you have a function that has clear and specific pre-conditions, you know what you have to do in order to use it correctly.  It can then give clear and specific post-conditions, and you can use these to reason further about your code.  On the other hand, if the function can, in practice, take any input then you have learned little.  And if it can do all sorts of different things - log a message, return an arbitrary "default" value, etc., - then you have nothing to work with for proving or verifying the rest of your code.