Program logic bugs vs input/environmental errors

[Walter Bright via Digitalmars-d]

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.