I want this so badly, please implement
Adam D. Ruppe via Digitalmars-d
digitalmars-d at puremagic.com
Thu Apr 7 13:36:28 PDT 2016
On Thursday, 7 April 2016 at 19:25:57 UTC, Steven Schveighoffer
wrote:
> I hear you. I'm actually fervently on the side of having a seg
> fault printout of some kind (an exception may not be the best
> choice because with a seg fault, you can't trust the stack).
Aye. I'm personally a bit lukewarm on it now because it is
possible to enable core dumps... but I often don't think to do it
until it is too late. So it would be really nice if it just
worked.
But I'd make the dereferences generated in the compiler to do
check it:
byte* a;
*a = 0;
Could be magically compiled into `a ||
makeNullPointerException(line), *a`, just like it does for
pointers.
In that case, throwing the Error should actually be OK because it
is caught before attempting to use it.
I guess the difficulty though is:
struct A { int a; int b; }
A* ptr;
ptr.b = 0;
because then, the pointer is null, but the pointer+offset isn't,
so maybe the codegen needs to be a big different. But the same
principle should apply - if the ptr is checked before attempting
the change, it is exactly the same as a RangeError - "safe" to
throw because the write hasn't actually occurred yet.
(I say "safe" with scare quotes because it is still a bug and
still not supposed to actually be recovered, you are supposed to
let the program die, but the error throw mechanism should be
fairly ok.)
> I'm sure you are in a similar situation with this.
> Instrumenting and running again is not only costly and time
> consuming, but may even subvert the actual problem (especially
> if it's timing sensitive).
Absolutely, and it is also really annoying when it happens
because of a user request.
So a web server dies with a RangeError because of some POST data.
What was the user submission that killed it? POST data isn't
ordinarily logged, so I have no idea and cannot reproduce. (I
typically just add assertions around it and try to debug from the
code without knowing the data.)
But, there's another thing that bothers me, and that is in the
development process: I like to quickly guess and check programs
over realistic data. Sometimes it can take a minute for the
program to run (like I said, there might be millions of lines)
and I'm trying to just quickly hammer this "script" out. Having
to stop, add log spamming, and run again kills the good attitude.
If I wanted to fight my programming language, I wouldn't be using
D!
More information about the Digitalmars-d
mailing list