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

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

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

Often there is no throw statement in the user code. See my answer in the newsgroup.


> Use asserts for that. Asserts are designed for that, and are pretty good at it.

Have you seen asserts used to pre-test I/O actions in D script-like programs? I've never seen them in the wild. Large programs catch exceptions and offer meaningful error messages, windows, etc. And script-like programs just show the exception and stack trace.

--

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

Brad Anderson <eco@gnuk.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eco@gnuk.net

--- Comment #12 from Brad Anderson <eco@gnuk.net> ---
Generally speaking, the __FILE__/__LINE__ trick sounds like a perfect example of something you put in a Debug build and leave out of a Release build. It can be genuinely useful during development while the program's logic is still being hammered out but it's often not useful or desired to show this information to end users.

--

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

Ketmar Dark <ketmar@ketmar.no-ip.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ketmar@ketmar.no-ip.org

--- Comment #13 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
that's why i HATE "release builds". if "release build" crashes, it's a whole lot of hell to extract any useful info from the crash to fill bugreport.

the whole thing with "release builds" should die. program must not crash. period. but IF it crashed, it must spit out ALOT of info, line numbers, backtraces, various internal states, and so on. so developer will NEVER need to ask to "run thing debug build please, and try to reproduce the bug, 'cause i can't see where that message comes from and why." it's a PITA to ask users to do something like that.

--

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

Vladimir Panteleev <thecybershadow@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thecybershadow@gmail.com

--

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

Stewart Gordon <smjg@iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg@iname.com

--- Comment #14 from Stewart Gordon <smjg@iname.com> ---
(In reply to Brad Anderson from comment #12)
> Generally speaking, the __FILE__/__LINE__ trick sounds like a perfect example of something you put in a Debug build and leave out of a Release build. It can be genuinely useful during development while the program's logic is still being hammered out but it's often not useful or desired to show this information to end users.

We already have this facility.  It's called a stack trace.

--

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

--- Comment #15 from bearophile_hugs@eml.cc ---
(In reply to Stewart Gordon from comment #14)

> We already have this facility.  It's called a stack trace.

If I run this:


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)
----------------
0x0040445B in @safe shared(core.stdc.stdio._iobuf)*
std.exception.__T12errnoEnforceTPOS4core4stdc5stdio6_iobufVAyaa11_7374645c737464696f2e64Vki364Z.errnoEnforce(shared(core.stdc.stdio._iobuf)*,
lazy immutable(char)[])
0x00402406 in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv
0x004023DB in void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll()
0x004022F1 in _d_run_main
0x00402100 in main
0x00414C7D in mainCRTStartup
0x7732D3C9 in BaseThreadInitThunk
0x771B1603 in RtlInitializeExceptionChain
0x771B15D6 in RtlInitializeExceptionChain


Where's the line number 3 of the user code that fails to open the file?

--

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

--- Comment #16 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
(In reply to bearophile_hugs from comment #15)
> Where's the line number 3 of the user code that fails to open the file?
switch to GNU/Linux and GDC, gdc stacktrace knows how to decode debug info:

=== cut ===
0xb7462159 ref std.stdio.File std.stdio.File.__ctor(immutable(char)[],
const(char[]))
        ../../../../gcc-4.9.1/libphobos/src/std/stdio.d:389
0x8049ce4 _Dmain
        /tmp/z00.d:3
=== cut ===

;-)

--

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

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@dawg.eu

--- Comment #17 from Martin Nowak <code@dawg.eu> ---
The file and line information is an inherent part of our Throwable class, so of
course everyone is forwarding __FILE__ and __LINE__ [1].
We could replace the location info by teaching stack traces how to read debug
info, see bug 11870.

[1]: https://github.com/D-Programming-Language/druntime/blob/36736e430b0c5299cf2ab9875be3b36236185f3b/src/object.di#L321

--

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

--- Comment #18 from Stewart Gordon <smjg@iname.com> ---
(In reply to bearophile_hugs from comment #15)
> Where's the line number 3 of the user code that fails to open the file?

Good question.  Did you compile in debug info (-g switch)?  (I'm at work at the
moment, so not in a position to try it myself and see.)

--

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

--- Comment #19 from bearophile_hugs@eml.cc ---
(In reply to Stewart Gordon from comment #18)

> Did you compile in debug info (-g switch)?

Yes, if you don't use -g the stack trace looks naked like:

std.exception.ErrnoException@std\stdio.d(367): Cannot open file
`some_file1.txt' in mode `rb' (No such file or directory)
----------------
0x00403E23
0x00402F82
0x00402F57
0x00402E6D
0x004020FF
0x7798D3C9 in BaseThreadInitThunk
0x77B31603 in RtlInitializeExceptionChain
0x77B315D6 in RtlInitializeExceptionChain

--