dereferencing null

[Chad J]

On 03/04/2012 11:39 PM, Adam D. Ruppe wrote:
> On Monday, 5 March 2012 at 03:24:32 UTC, Chad J wrote:
>> News to me. I've had bad runs with that back in the day, but maybe
>> things have improved a bit.
>
> Strangely, I've never had a problem with gdb and D,
> as far back as 2007.
> (at least for the basic stack trace kind of stuff).
>
> But, yeah, they've been improving a lot of things
> recently too.
>
>> Non-nullable types would be really cool right about now.
>
> Huh, I thought there was one in phobos by now.
>
> You could spin your own with something like this:
>
> struct NotNull(T) {
> T t;
> alias t this;
> @disable this();
> @disable this(typeof(null));
> this(T value) {
> assert(value !is null);
> t = value;
> }
>
> @disable typeof(this) opAssign(typeof(null));
> typeof(this) opAssign(T rhs) {
> assert(rhs !is null);
> t = rhs;
> return this;
> }
> }
>
>
> This will catch usages of the null literal at
> compile time, and other null references at runtime
> as soon as you try to use it.
>
> With the disabled default constructor, you are forced
> to provide an initializer when you use it, so no
> accidental null will slip in.
>
> The alias this means NotNull!T is substitutable for T,
> so you can drop it into existing apis.
>

That's cool.  Maybe someone should stick it in Phobos?  I haven't had 
time to try it yet though.  I also didn't know about @disabled; that's a 
nifty addition.

>> It's that I simply cannot expect users to run my code in a debugger.
>
> :) I'm lucky if I can get more from my users than
> "the site doesn't work"!
>

Ugh!

This sort of thing has happened in non-web code at work.  This is on an 
old OpenVMS system with a DIBOL derivative language and people accessing 
it from character-based terminals.  Once I finally got the damn system 
capable of broadcasting emails reliably (!!) and without using disk IO 
(!!), I started having it send me stack traces of things before it dies. 
  The only thing left that's really annoying about this is I still have 
no way of determining whether an exception is going to be caught or not 
before I send out the email, so I can't use it in cases where things are 
expected to throw sometimes (ex: end of file exception, key not found 
exception).  So I can only do this effectively for errors that are 
pretty much guaranteed to be bad news.

I hope Phobos will have (or already have) the ability to print stack 
traces without crashing from an exception.  There are (surprisingly 
frequent) times when something abnormal happens and I want to know why, 
but it is safe to continue running the program and the last thing I want 
to do is crash on the user.  In those cases it is very useful for me to 
grab a stacktrace and send it to myself in an email.

I can definitely see web stuff being a lot less cut-and-dry than this 
though, and also having a lot of blind-spots in technologies that you 
can't control very easily.

>> The problem is that they don't help me when I missed a spot and didn't
>> use assertions, contracts, or invariants.
>
> Aye, I've had it happen. The not null types might help,
> though tbh I've never used anything like this in practice
> so maybe not. I don't really know.