I have recently closed this bug report about File error messages: http://d.puremagic.com/issues/show_bug.cgi?id=4911

Because now this program gives a better error message:


import std.stdio: File;
void foo() {
    auto f = File("test.raw", "r");
    f.write("hello");
}
void bar() {
    foo();
}
void main() {
    bar();
}



With DMD 2.053 it gives at runtime (using -g):

std.exception.ErrnoException@std\stdio.d(286): Cannot open file `test.raw' in
mode `r' (No such file or directory)
----------------
...\test.d(8): void test.bar()
...\test.d(10): _Dmain
----------------



The error is generated by this part of the File struct:

    this(string name, in char[] stdioOpenmode = "rb")
    {
        p = new Impl(errnoEnforce(.fopen(name, stdioOpenmode),
                        text("Cannot open file `", name, "' in mode `",
                                stdioOpenmode, "'")),
                1, name);
    }



But the stack trace stops at the function before the one that has generated the error. I don't know enough about the implementation of the exceptions, but is it possible to invent a Phobos function that returns the name of the penultimate function? To be used like this:


    this(string name, in char[] stdioOpenmode = "rb")
    {
        p = new Impl(errnoEnforce(.fopen(name, stdioOpenmode),
                        text("File usage in function `", lastFunctionName(),
                             "', cannot open file `", name, "' in mode `",
                             stdioOpenmode, "'")),
                1, name);
    }


That prints something like:

std.exception.ErrnoException@std\stdio.d(286): File usage in function `test.foo', cannot open file `test.raw' in mode `r' (No such file or directory)

Bye,
bearophile

Sorry, I don't quite understand the problem – the exception message describes what happened, and the stack trace points to the location. The only thing that strikes me as strange here is that file.foo itself isn't included in the backtrace, but I'd say that's a bug in the exception handling code, not related to File itself. Or did I miss anything?

By the way, this is how the output looks on OS X:

std.exception.ErrnoException@std/stdio.d(286): Cannot open file `test.raw' in mode `r' (No such file or directory)
----------------
5   test                                0x000347fa @safe shared(core.stdc.stdio._iobuf)* std.exception.errnoEnforce!(shared(core.stdc.stdio._iobuf)*, "std/stdio.d", 286).errnoEnforce(shared(core.stdc.stdio._iobuf)*, lazy immutable(char)[]) + 90
6   test                                0x00033443 ref std.stdio.File std.stdio.File.__ctor(immutable(char)[], const(char[])) + 87
7   test                                0x00002aea void test.foo() + 58
8   test                                0x00002b2f void test.bar() + 11
9   test                                0x00002aab _Dmain + 11
10  test                                0x000146bb extern (C) int rt.dmain2.main(int, char**).void runMain() + 23
11  test                                0x00014265 extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void delegate()) + 29
12  test                                0x00014703 extern (C) int rt.dmain2.main(int, char**).void runAll() + 59
13  test                                0x00014265 extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void delegate()) + 29
14  test                                0x000141ff main + 179
15  test                                0x00002a95 start + 53
----------------

No line numbers, unfortunately, but the whole call stack is present.

David


On 6/26/11 2:53 PM, bearophile wrote:
> I have recently closed this bug report about File error messages:
> http://d.puremagic.com/issues/show_bug.cgi?id=4911
>
> Because now this program gives a better error message:
>
>
> import std.stdio: File;
> void foo() {
>      auto f = File("test.raw", "r");
>      f.write("hello");
> }
> void bar() {
>      foo();
> }
> void main() {
>      bar();
> }
>
>
>
> With DMD 2.053 it gives at runtime (using -g):
>
> std.exception.ErrnoException@std\stdio.d(286): Cannot open file `test.raw' in
> mode `r' (No such file or directory)
> ----------------
> ...\test.d(8): void test.bar()
> ...\test.d(10): _Dmain
> ----------------
>
>
>
> The error is generated by this part of the File struct:
>
>      this(string name, in char[] stdioOpenmode = "rb")
>      {
>          p = new Impl(errnoEnforce(.fopen(name, stdioOpenmode),
>                          text("Cannot open file `", name, "' in mode `",
>                                  stdioOpenmode, "'")),
>                  1, name);
>      }
>
>
>
> But the stack trace stops at the function before the one that has generated the error. I don't know enough about the implementation of the exceptions, but is it possible to invent a Phobos function that returns the name of the penultimate function? To be used like this:
>
>
>      this(string name, in char[] stdioOpenmode = "rb")
>      {
>          p = new Impl(errnoEnforce(.fopen(name, stdioOpenmode),
>                          text("File usage in function `", lastFunctionName(),
>                               "', cannot open file `", name, "' in mode `",
>                               stdioOpenmode, "'")),
>                  1, name);
>      }
>
>
> That prints something like:
>
> std.exception.ErrnoException@std\stdio.d(286): File usage in function `test.foo', cannot open file `test.raw' in mode `r' (No such file or directory)
>
> Bye,
> bearophile

David Nadlinger:

> Sorry, I don't quite understand the problem – the exception message describes what happened, and the stack trace points to the location. The only thing that strikes me as strange here is that file.foo itself isn't included in the backtrace,

Right, that's my problem. I'd like to know the function and line number where the File constructor is called.


> but I'd say that's a bug in the exception handling code, not related to File itself. Or did I miss anything?

You are probably right that File is not the cause of the problem.


> By the way, this is how the output looks on OS X:
> ...
> No line numbers, unfortunately, but the whole call stack is present.

Such stack trace is more than enough for me :-) But the implementation of exception handling differs between different operating systems, so I don't know if there is a bug in the Windows stack frame printing, or if there is a more structural problem that can't be solved. I will probably file a bug report for this Windows stack frame, then.

Bye and thank you,
bearophile