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!

Reply via email to