On 9/29/14 10:48 AM, Jacob Carlborg wrote:
On 29/09/14 13:51, Steven Schveighoffer wrote:
That makes no sense. The opening of the file is subject to issues with
the filesystem, which means they may be environmental or user errors,
not programming errors. But that doesn't mean the opening of the file
failed because the file doesn't exist, it could be an error in how you
construct the file name.
What about:
File f;
f.open(null);
Is that an environmental error or User error?
That depends on what "open" expect from its argument. In this particular
case, in D, "null" is the same as the empty string. I don't see why that
technically shouldn't be allowed.
My entire point is, it doesn't matter what is expected or what is
treated as "correct." what matters is where the input CAME from. To a
library function, it has no idea. There is no extra type info saying
"this parameter comes from user input."
Of course, you can specify that "open" expects a string argument with
the length that is greater then 0, in that case it's a bug by the
programmer that uses the "open" function.
Is it? I can think of cases where it's programmer error, and cases where
it's user error.
There are also better example functions, but I'm focusing on File
because that's what this thread is about.
The largest issue I see with this whole scheme is that exceptions can be
turned into errors, but not the reverse. Once an error is thrown, it's
pretty much game over. So defensive coding would suggest when you don't
know the answer, throw an exception, and something higher up would say
"Oh, that is really a program error, rethrowing"
But expecting developers to do this at EVERY CALL is really impossible.
My expectation is that an exception is really an error unless caught. It
would be nice to postpone generating the stack trace unless the
exception is caught outside the main function. I don't know enough about
how exceptions work to know if this is possible or not.
-Steve
