newbie problem with nothrow
Steven Schveighoffer via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Tue Nov 1 09:19:11 PDT 2016
On 11/1/16 11:54 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
> On Tuesday, November 01, 2016 10:57:38 Steven Schveighoffer via Digitalmars-
> d-learn wrote:
>> On 10/31/16 6:29 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
>>> assert(0, "format threw when it shouldn't be possible.");
>>
>> This turns into a non-printing seg fault when compiled in release mode.
>
> I'm well aware of that, and I don't see that as a problem. A message might
> be nice, but the key thing is that it kills the program if there's a
> problem, and given Mike's point about the C layer, having it segfault is
> potentially preferable to throwing an Error to kill the program.
I disagree that avoiding the message printing is not a problem. I have
had the unpleasant experience of having a program that dies on the order
of 1-2 weeks with "SegFault", without any way of instrumenting the
failure (debugging not an option, doesn't fail on dev machine). Just a
tiny hint of what the problem is, can save weeks if not months of searching.
A little while ago, I added an internal tool to both abort a program,
and print a message (including file and line number) to druntime. It's
not exactly public, but may be useful to expose. It should be callable
from any location, including signal handlers.
https://github.com/dlang/druntime/blob/master/src/core/internal/abort.d
>> Is there not some assumeNoThrow wrapper somewhere?
>
> Someone added assemWontThrow to std.exception semi-recently, but I'd be very
> surprised if it didn't incur performance overhead such that I'd just as soon
> use an explicit try-catch and be done with it.
The function I'm imagining shouldn't add any overhead...
-Steve
More information about the Digitalmars-d-learn
mailing list