This issue comes up over and over, in various guises. I feel like Yosemite Sam here:

    https://www.youtube.com/watch?v=hBhlQgvHmQ0

In that vein, Exceptions are for either being able to recover from input/environmental errors, or report them to the user of the application.

When I say "They are NOT for debugging programs", I mean they are NOT for debugging programs.

assert()s and contracts are for debugging programs.

After all, what would you think of a compiler that spewed out messages like this:

   > dmd test.d
   test.d(15) Error: missing } thrown from dmd/src/parse.c(283)

?

See:

    https://issues.dlang.org/show_bug.cgi?id=13543

As for the programmer wanting to know where the message "missing }" came from,

    grep -r dmd/src/*.c "missing }"

works nicely. I do that sort of thing all the time. It really isn't a problem.

Walter Bright:

> As for the programmer wanting to know where the message "missing }" came from,
>
>     grep -r dmd/src/*.c "missing }"
>
> works nicely. I do that sort of thing all the time. It really isn't a problem.

grep is not useful for the purposes explained in issue 13543 because the file name is often inside a string variable, that is initialized elsewhere or generated in some way. So the exception is useful to know where's the instruction in user code that has tried the failed I/O action, as I've explained in that issue.

Bye,
bearophile

On 9/27/2014 4:33 PM, bearophile wrote:
> Walter Bright:
>
>> As for the programmer wanting to know where the message "missing }" came from,
>>
>>     grep -r dmd/src/*.c "missing }"
>>
>> works nicely. I do that sort of thing all the time. It really isn't a problem.
>
> grep is not useful for the purposes explained in issue 13543 because the file
> name is often inside a string variable, that is initialized elsewhere or
> generated in some way. So the exception is useful to know where's the
> instruction in user code that has tried the failed I/O action, as I've explained
> in that issue.

Even if that is what you wanted, you won't get that from FileException, as it will only show file/lines emanating from calls inside std.file, not from higher level callers.

Besides, take a bit of care when formulating a string for exceptions, and you won't have any trouble grepping for it. This isn't rocket science.

Presenting internal debugging data to users for input/environmental errors is just bad programming practice. We shouldn't be enshrining it in Phobos and presenting it as a professional way to code.

On Sat, Sep 27, 2014 at 04:42:18PM -0700, Walter Bright via Digitalmars-d wrote:
> On 9/27/2014 4:33 PM, bearophile wrote:
> >Walter Bright:
> >
> >>As for the programmer wanting to know where the message "missing }" came from,
> >>
> >>    grep -r dmd/src/*.c "missing }"
> >>
> >>works nicely. I do that sort of thing all the time. It really isn't a problem.
> >
> >grep is not useful for the purposes explained in issue 13543 because the file name is often inside a string variable, that is initialized elsewhere or generated in some way. So the exception is useful to know where's the instruction in user code that has tried the failed I/O action, as I've explained in that issue.
> 
> Even if that is what you wanted, you won't get that from FileException, as it will only show file/lines emanating from calls inside std.file, not from higher level callers.
> 
> Besides, take a bit of care when formulating a string for exceptions, and you won't have any trouble grepping for it. This isn't rocket science.
> 
> Presenting internal debugging data to users for input/environmental errors is just bad programming practice. We shouldn't be enshrining it in Phobos and presenting it as a professional way to code.

My take on this, is that uncaught exceptions are a program bug. Any messages displayed to the user ought to come from a catch block that not only prints the exception message (*without* things like line numbers and stack traces, btw), but also provides context (e.g., "Error in configuration file section 'abc': illegal field value" instead of just "illegal field value" with no context of where it might have been triggered).

Uncaught exceptions (which ideally should only be Errors, not Exceptions) are a program bug that ought to be fixed. In the case that somehow one managed to elude your catch blocks, the full debug infodump (source file, line number, stack trace) is useful for users to hand back to you in a bug report, so that you can track down the problem. The user should not be expected to understand the infodump from an uncaught exception, whereas a message printed from a catch block ought to be user-understandable (like "can't open 'myphoto.jpg': file not found", not "internal error on line 12345" which makes no sense to a user).


T

-- 
Laissez-faire is a French term commonly interpreted by Conservatives to mean 'lazy fairy,' which is the belief that if governments are lazy enough, the Good Fairy will come down from heaven and do all their work for them.

Walter Bright:

> Even if that is what you wanted, you won't get that from FileException, as it will only show file/lines emanating from calls inside std.file, not from higher level callers.

Can't we use the template arguments like __LINE__ to offer the line of code in the IO function in user code?


> Besides, take a bit of care when formulating a string for exceptions, and you won't have any trouble grepping for it. This isn't rocket science.

The exception is generated inside library code, not in user code. There's nothing to grep in the user code. The D script often looks like this:

void main() {
    import std.stdio;
    auto file_name = "some_file;
    // some code here
    auto file_name1 = file_name ~ "1.txt";
    auto f1 = File(file_name1);
    // some code here
    auto file_name2 = file_name ~ "2.txt";
    auto f2 = File(file_name2, "w");
    // some code here
}


> Presenting internal debugging data to users for input/environmental errors is just bad programming practice.7 We shouldn't be enshrining it in Phobos and presenting it as a professional way to code.

The file/line of code is not meant to replace serious practices for dealing with I/O failures in serious D programs.

Bye,
bearophile

On 9/27/2014 4:55 PM, H. S. Teoh via Digitalmars-d wrote:
> My take on this, is that uncaught exceptions are a program bug.

Not to me. Custom messages would be better, but the exception message should be serviceable.


> Uncaught exceptions (which ideally should only be Errors, not
> Exceptions) are a program bug that ought to be fixed. In the case that
> somehow one managed to elude your catch blocks, the full debug infodump
> (source file, line number, stack trace) is useful for users to hand back
> to you in a bug report, so that you can track down the problem. The user
> should not be expected to understand the infodump from an uncaught
> exception, whereas a message printed from a catch block ought to be
> user-understandable (like "can't open 'myphoto.jpg': file not found",
> not "internal error on line 12345" which makes no sense to a user).

Whoa, Camel! You're again thinking of Exceptions as a debugging tool.

On 9/27/2014 4:59 PM, bearophile wrote:
> Walter Bright:
>
>> Even if that is what you wanted, you won't get that from FileException, as it
>> will only show file/lines emanating from calls inside std.file, not from
>> higher level callers.
>
> Can't we use the template arguments like __LINE__ to offer the line of code in
> the IO function in user code?

We could, but again, WHOA CAMEL!

Also, one should be careful in using __LINE__ in a template, as it will be forced to generate a new instantiation with every use.


>> Besides, take a bit of care when formulating a string for exceptions, and you
>> won't have any trouble grepping for it. This isn't rocket science.
>
> The exception is generated inside library code, not in user code. There's
> nothing to grep in the user code. The D script often looks like this:
>
> void main() {
>      import std.stdio;
>      auto file_name = "some_file;
>      // some code here
>      auto file_name1 = file_name ~ "1.txt";
>      auto f1 = File(file_name1);
>      // some code here
>      auto file_name2 = file_name ~ "2.txt";
>      auto f2 = File(file_name2, "w");
>      // some code here
> }

Come on. What is hard about "Cannot open file `xxxx` in mode `xxxx`", then you grep for "Cannot open file" ?

Let's try it:

  > grep "Cannot open file" *.d
  stdio.d:      text("Cannot open file `", name, "' in mode `",
  stdio.d://    new StdioException("Cannot open file `"~fName~"' for reading"));
  stdio.d://    new StdioException("Cannot open file `"~fName~"' for reading"));

Besides, File doesn't throw a FileException and doesn't add caller's __FILE__ and __LINE__.

If you're seriously proposing adding __FILE__ and __LINE__ to every function call, then D is the wrong language. This would have disastrous bloat and performance problems. You mentioned Python and Ruby, both of which are well known for miserable performance.

Building the equivalent of a symbolic debugger into RELEASED D code is just not acceptable.


>> Presenting internal debugging data to users for input/environmental errors is
>> just bad programming practice.7 We shouldn't be enshrining it in Phobos and
>> presenting it as a professional way to code.
>
> The file/line of code is not meant to replace serious practices for dealing with
> I/O failures in serious D programs.

That's exactly what you're doing with it.

On 09/28/2014 02:40 AM, Walter Bright wrote:
> On 9/27/2014 4:55 PM, H. S. Teoh via Digitalmars-d wrote:
>> My take on this, is that uncaught exceptions are a program bug.
>
> Not to me. ...

It is not worth fixing if a program terminates with a stack trace?

On 9/27/2014 5:54 PM, Timon Gehr wrote:
> On 09/28/2014 02:40 AM, Walter Bright wrote:
>> On 9/27/2014 4:55 PM, H. S. Teoh via Digitalmars-d wrote:
>>> My take on this, is that uncaught exceptions are a program bug.
>>
>> Not to me. ...
>
> It is not worth fixing if a program terminates with a stack trace?
>

I never was in favor of adding the stack trace output, either, for the same reason. Exceptions are not programming bugs.

For Errors, a case can be made for them.

On 9/27/14 7:15 PM, Walter Bright wrote:

> When I say "They are NOT for debugging programs", I mean they are NOT
> for debugging programs.

Library code often cannot make that choice. The issue with exceptions vs. errors is that often you don't know where the input comes from.

e.g.:

auto f = File(someInternalStringThatIsCorrupted) -> error
auto f = File(argv[1]) -> exception

How does File know what it's target file name came from?

-Steve