digitalmars.D.learn - Last frame?
- bearophile (42/42) Jun 26 2011 I have recently closed this bug report about File error messages:
- David Nadlinger (33/75) Jun 26 2011 Sorry, I don't quite understand the problem – the exception message
- bearophile (6/15) Jun 26 2011 You are probably right that File is not the cause of the problem.
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
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
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