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.
