On 04/02/2013 08:16 PM, Jesse Phillips wrote:> On Tuesday, 2 April 2013
at 19:10:47 UTC, Ali Çehreli wrote:
>> > 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."
An assert() is for situations that the programmer knows (!) to never
exist. If my foo() function called my bar() function with 42, it is an
invalid state. That is when assert() failed and threw Error.
The Error is not thrown before entering the invalid state but at the
first point that the error has been discovered. In that regard, the
program is in a bad state.
> 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).
There are some issues with contract programming in D. For example, some
people think that whether the pre-conditions of a module to be compiled
should be determined by the user of that module, not the library (e.g.
Phobos).
Because the above is not the case today, if I write a function, I cannot
put the function pre-conditions in 'in' blocks because I don't know
whether my function is being called as an implementation of my module or
as an API function. The API function foo() may also be used as part of
the implementation of the same module. (Maybe the same pre-condition
checks should be repeated in the 'in' block and in the body; as asserts
and corresponding enforces.)
For that reason, in general, I think that pre-conditions should by
default be implemented as enforce() calls in the function body, not
assert() calls in the 'in' blocks.
With that aside, a failed assert() in an 'in' block should still point
at an invalid program state.
> 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);
We are in agreement that it would be impossible to prove one way or the
other whether removing the file would be the right thing to do or
whether it will succeed. The difference in thinking is whether that
should be attempted at all when some part of the code has determined
that something is wrong with the program.
Ali
