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

bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc

--- Comment #1 from bearophile_hugs@eml.cc ---
I guess a FileException should give the line number of the *user* code where he/she has performed a failed file operation.

--

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

--- Comment #2 from Walter Bright <bugzilla@digitalmars.com> ---
(In reply to bearophile_hugs from comment #1)
> I guess a FileException should give the line number of the *user* code where he/she has performed a failed file operation.

Once again, Exceptions are NOT for debugging user code.

--

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

--- Comment #3 from bearophile_hugs@eml.cc ---
(In reply to Walter Bright from comment #2)
> (In reply to bearophile_hugs from comment #1)
> > I guess a FileException should give the line number of the *user* code where he/she has performed a failed file operation.
> 
> Once again, Exceptions are NOT for debugging user code.

I don't agree. If I open a file, and the opening fails, I'd like the exception to tell me what damned line of my code has tried to open that file. Exceptions are useful to debug user code.

--

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

--- Comment #4 from Walter Bright <bugzilla@digitalmars.com> ---
(In reply to bearophile_hugs from comment #3)
> (In reply to Walter Bright from comment #2)
> > Once again, Exceptions are NOT for debugging user code.
> 
> I don't agree. If I open a file, and the opening fails, I'd like the exception to tell me what damned line of my code has tried to open that file. Exceptions are useful to debug user code.

This is a serious misuse of Exceptions.

What do your customers think when your apps are showing them file/line pointing to your internal source code when a file doesn't exist?

I've never even heard of an app that would assault users with such "error" messages, except for D apps.


The construct to debug code is "assert", not "throw".

Cue my usual rant about confusion between what is a programming logic error and what is an input/environmental error, and the conflation of the methods for dealing with them.

--

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

--- Comment #5 from bearophile_hugs@eml.cc ---
(In reply to bearophile_hugs from comment #3)

> If I open a file, and the opening fails, I'd like the
> exception to tell me what damned line of my code has tried to open that
> file.

- - - - - - - - - - - - - - -

A Python script (both files are missing):


f1 = open("some_file1.txt")
f2 = open("some_file2.txt")


Gives information that helps to locate what's the line that has tried to open the missing file:

Traceback (most recent call last):
  File "...\test.py", line 1, in <module>
    f1 = open("some_file1.txt")
IOError: [Errno 2] No such file or directory: 'some_file1.txt'

- - - - - - - - - - - - - - -

A similar D program gives line number inside the library code, but I'd like an exception that tells me that the problem is in test.d at line 3:

void main() {
    import std.stdio;
    auto f1 = File("some_file1.txt");
    auto f2 = File("some_file2.txt");
}


std.exception.ErrnoException@std\stdio.d(364): Cannot open file
`some_file1.txt' in mode `rb' (No such file or directory)
----------------
0x0040447B in @safe shared(core.stdc.stdio._iobuf)*
std.exception.__T12errnoEnforceTPOS4core4stdc5stdio6_iobufVAyaa11_7374645c737464696f2e64Vki364Z.errnoEnforce(shared(core.stdc.stdio._iobuf)*,
lazy immutable(char)[])
...

- - - - - - - - - - - - - - -

--

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

--- Comment #6 from bearophile_hugs@eml.cc ---
(In reply to Walter Bright from comment #4)

> This is a serious misuse of Exceptions.
> 
> What do your customers think when your apps are showing them file/line pointing to your internal source code when a file doesn't exist?

It's a basic information, better than no information at all. If my app tells me a file is missing then maybe I can find it. But see below.


> I've never even heard of an app that would assault users with such "error" messages, except for D apps.
> 
> 
> The construct to debug code is "assert", not "throw".

Adding the line number of the user code that has caused the IO exception is handy to fix little script-like D programs.

A IO exception is meant to be caught by your large serious programs, it's never meant to be shown to users.

--

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

--- Comment #7 from Walter Bright <bugzilla@digitalmars.com> ---
(In reply to bearophile_hugs from comment #6)
> A IO exception is meant to be caught by your large serious programs, it's never meant to be shown to users.

1. You are trying to use exceptions to debug the program. This is utterly wrong.

2. Exceptions are meant to provide information to the user of the app, not the programmer of the app.

--

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

--- Comment #8 from bearophile_hugs@eml.cc ---
(In reply to Walter Bright from comment #7)

> 1. You are trying to use exceptions to debug the program. This is utterly wrong.

It's what millions of people are doing every day in Python, Ruby, etc. If you are writing a 50 lines long script program that loads some files, you are thankful when the exception tells you what line of your code has opened a missing file.

In such small D programs you don't want to add assert(isOpen(...) &&
isWriteable(...)) and even if you do that, there are other problems, like
asserts and file ops getting out of sync, file state changing between the
assert and the file operation, etc.


> 2. Exceptions are meant to provide information to the user of the app, not the programmer of the app.

As an user of the app, the app should tell me that a file is missing with a nice pop up window, or better, not with exceptions. But not all D programs are large, and giving the line number in the exception message is a first basic information when the code has bugs or when the D program is not an app, but a little script-like (and I write many such tiny D programs).

--

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

--- Comment #9 from Walter Bright <bugzilla@digitalmars.com> ---
(In reply to bearophile_hugs from comment #8)
> It's what millions of people are doing every day in Python, Ruby, etc. If you are writing a 50 lines long script program that loads some files, you are thankful when the exception tells you what line of your code has opened a missing file.

I doubt I'd have trouble locating a 'throw' statement in a 50 line program. I don't believe you would, either.


> In such small D programs you don't want to add assert(isOpen(...) &&
> isWriteable(...)) and even if you do that, there are other problems, like
> asserts and file ops getting out of sync, file state changing between the
> assert and the file operation, etc.

Sorry, I think this is rubbish. (You also do not want to catch Exception messages just to filter out the file/line to then present the message to the user.)

> > 2. Exceptions are meant to provide information to the user of the app, not the programmer of the app.
> 
> As an user of the app, the app should tell me that a file is missing with a nice pop up window,

Console apps don't need to that, and it's pretty easy for a gui app to provide a top level handler that pops up a window.

> or better, not with exceptions. But not all D programs
> are large, and giving the line number in the exception message is a first
> basic information when the code has bugs

Again, Exceptions are NOT A DEBUGGING TOOL and should NOT BE THROWN WHEN BUGS ARE DETECTED. Use asserts for that. Asserts are designed for that, and are pretty good at it.

--

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

--- Comment #10 from Walter Bright <bugzilla@digitalmars.com> ---
To put things more clearly, Exceptions are for:

1. so code can recover cleanly from input/environmental errors
2. if (1) is not possible, report the error to the app user in a manner that is
sensible to the app user


They are NOT for:

1. so the code can recover from internal programming bugs 2. reporting internal programming bugs to the app user

--