On Tuesday, 2 April 2013 at 19:10:47 UTC, Ali Çehreli wrote:
> We can still throw exceptions in production, I don't tend to
use this,
> but maybe this would be a time to say "invalid state stop."
But then how
> do you distinguish it from "fix your program?"
(I am not sure that I understand that comment correctly.)
(meant to say: we can still throw Errors in production.)
Errors currently really get used to identify conditions that
could cause an invalid state as the check may not always be there.
> I've mostly enjoyed having temporary files being cleaned up
upon some
> range access error which has no effect on my removing files
that are no
> longer valid.
The problem is, the runtime cannot know that it will be doing
what you really wanted. The incorrect program state may result
in deleting the wrong file.
See above, the state isn't invalid. The error is thrown which is
stating, "hey, buddy, good thing you didn't flip that release
switch as I'm about to do something I shouldn't be."
However D does allow nothrow functions to throw Errors. I
wouldn't say this would cause the program enter into an invalid
state (memory corruption) but it would be a bad state (contract
violations).
Take the RangeError thrown when you pop an empty range. Under
what scenario would receiving one of these would indicate that my
file isn't correct for deletion (any more so than say a
ConvException from the same range).
auto myFile = "some.tmp";
scope(exit) remove(myFile);
// setup code here
manipulateFileRange(range);
setup code could of course assign a pointer of myFile to range
and range could make modifications but doing so could just as
likely throw a ConvException (or others) before you hit a
RangeError.
