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