www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Last frame?

reply bearophile <bearophileHUGS lycos.com> writes:
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
Jun 26 2011
parent reply David Nadlinger <see klickverbot.at> writes:
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
Jun 26 2011
parent bearophile <bearophileHUGS lycos.com> writes:
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
Jun 26 2011