Leandro Lucarella wrote:
Andrei Alexandrescu, el 29 de octubre a las 12:33 me escribiste:
Bill Baxter wrote:
I think bool remove(key) is better than all other designs suggested so far.
I agree with the folks who say it's error-prone. I can just see
myself now removing a key I know is in the dictionary and being
baffled when my program fails somewhere later on because I typed
aa.remove("theKey") when it should have been aa.remove("thekey"). I
knew it was there so I didn't want to clutter up my code with a check
for it.
I don't find this reasonable. If you know removal must have
succeeded, just type enforce(aa.remove("theKey")). I don't think
I don't agree, this is like saying you should bound-check every array
access. I think it's nice to have safety by default.
remove from an associative array is not unsafe.
If you are expecting
to have an error, you will be extra careful to spell the key correctly.
This should cover the cases where you are distracted and not expecting any
errors.
I think the check could be done in non-release mode only though, just
like bound checking.
Bounds checking is eliminated in release mode solely for efficiency
reasons. There is no other good reason to eliminate checks. But in the
case of remove, the amount of work done is consistent enough to make a
check negligible.
that's the overwhelmingly common case though, and if it's, say,
about 50/50, then it's much more sensible to have a non-throwing
primitive than a throwing one. And it looks like defining two
primitives just to save a call to enforce is not a good design.
This is one case where I think practicality beats purity, because the
whole point of throwing an exception is for the cases you don't expect it
to fail. Again, think of array bounds, you can force the programmer to add
lots of enforce() in the code and remove bound checking from the compiler.
I can't think of array bounds. The situations are completely unrelated.
Andrei
