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