On 9/29/14 2:43 PM, Jeremy Powers via Digitalmars-d wrote:
On Mon, Sep 29, 2014 at 8:13 AM, Steven Schveighoffer via Digitalmars-d
<digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
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."
From the method's view, parameters passed in are user input. Full stop.
This is missing the point of an exception. An uncaught exception is an
error which crashes the program. If you catch the exception, you can
handle it, but if you don't expect it, then it's a bug. Any uncaught
exceptions are BY DEFINITION programming errors.
One thing that seems to be talked around a bit here is the
separation/encapsulation of things. It is perfectly fine, and expected,
for a library method to throw exceptions on bad input to the method -
even if this input turns out to be a programming bug elsewhere. From
the standpoint of the method, it does not know (and does not care) where
the thing ultimately came from - all it knows is that it is input here,
and it is wrong.
What is being discussed here is removing the stack trace and printout
when an exception is thrown.
Imagine this error message:
myprompt> ./mycoolprogram
(1 hour later)
FileException: Error opening file xgghfsnbuer
myprompt>
Now what? xgghfsnbuer may not even be in the code anywhere. There may be
no hints at all as to what caused it to happen. You don't even know
which line of code YOU wrote that was causing the issue! You have to
examine every File open, and every call that may have opened a file, and
see if possibly that file name was passed into it.
Whereas if you get a trace, you can at least see where the exception
occurred, and start from there.
Now, RELYING on this printout to be your interface to the user, that is
incorrect design, I will agree. But one cannot possibly be expected to
handle every possible exception at every possible call so one can throw
an error in the cases where it actually is an error. D doesn't even
require listing the exceptions that may be thrown on the API (and no,
I'm not suggesting it should).
If you call a method with bad input, and fail to catch the resulting
exception, then _that_ is a bug, not the method throwing. It may be
perfectly recoverable to ignore/retry/whatever, or it may be a symptom
of something that should abort the program. But the method throwing
does not know or care.
Sure, but it doesn't happen. Just like people do not check return values
from syscalls.
The benefit of the exception printing is at least you get a trace of
where things went wrong when you didn't expect them to. Ignoring a
call's return value doesn't give any notion something is wrong until
much later.
-Steve
