Daniel Keep wrote:
Jeremie Pelletier wrote:
...
This is something for the runtime or the debugger to deal with. My
runtime converts access violations on windows or segfaults on linux into
exception objects, which unwind all the way down to main where it
catches into the unhandled exception handler (or crash handler) and I
get a neat popup with a "hello, your program crashed at this point, here
is a backtrace with resolved symbols and filenames along with current
registers and loaded modules, would you like a cup of coffee while you
solve the problem?". I sent that crash handler to D.announce last week too.
See my long explanation that NPEs are only symptoms; very rarely do they
put up a big sign saying "what ho; the problem is RIGHT HERE!"
The compiler won't be able to enforce *every* nonnull reference and
segfaults are bound to happen, especially with casting. While it may
prevent most of them, any good programmer would too, I don't remember
the last time I had a segfault on a null reference actually.
I do. It took a day and a half to track it back to the source.
Happens to me on some issues too, I don't ask for a workaround in the
compiler, I just learn my lesson and never repeat that error.
I can see what the point is with nonnull references, but I can also see
its not a bulletproof solution. ie "Object foo = cast(Object)null;"
would easily bypass the nonnull enforcement, resulting in a segfault the
system is trying to avoid.
Why lock the door when someone could break the window?
Easier to prove someone broke in when the window is shattered than if
someone just went through the door, stole your stuff and left without
any traces.
Why have laws when people could break them?
People break the law, some of them only for the challenge of it, some of
them to survive, some just don't care. Remove the laws and you remove
most of these behaviors you're trying to prohibit in the first place.
Most of the time laws are there so corporate criminals can get rid of
street criminals legally.
Why build a wall when someone could park a hydrogen bomb next to it?
They keep most people out, or in. Hydrogen bombs are not something you
expect the first guy on the street to own.
Why have a typesystem when you could use casting to put the float
representation of 3.14159 into a void* and then dereference it?
Because it also allows for countless different optimizations, at the
price of also being able to shoot your own foot.
There, four similar questions and four completely different answers. My
point is, there is no perfect all-around solution.
Casting is not an argument against non-null references because casting
can BREAK ANYTHING.
"Doctor, it hurts when I hammer nails into my shin."
"So stop doing it."
Why tell him to stop it? The guy will just kill himself at some point
and raise the collective IQ of mankind in the process. Same for
programming or anything else, if someone is dumb enough to repeat the
same mistake over and over, he should find a new domain to work in.
What about function parameters, a lot of parameters are optional
references, which are tested and then used into functions whose
parameters aren't optional. It would result in a lot of casts, something
that could easily confuse people and easily generate segfaults.
So what you're saying is: better to never, ever do error checking and
just start fixing things after they've broken?
No, but you shouldn't rule out the fact that they may break, no matter
what system you're working with.
And why is everything solved via casting? Look: here's a solution
that's less typing than a cast, AND it's safe. You could even put
nonnull it in object.d!
T notnull(U : T?, T)(U obj)
{
if( obj is null ) throw new NullException;
return cast(T) obj;
}
void foo(Quxx o)
{
o.doStuff;
}
void foo(Quxx? o)
{
foo(notnull(o));
}
Also slower than a cast if the compiler doesn't use -inline. Debug
builds are already painful enough as it is with realtime code.
Alls I'm saying is, nonnull references would just take the issue from
one place to another.
YES.
THAT'S THE POINT.
It would take the error from a likely unrelated location in the
program's execution and put it RIGHT where the mistake initially occurs!
That's a case for variable initialization, not nullable/non-null types.
A nonnull type does not guarantee the value will *never* be null, even
the simplest hack can get around it.
Like Walter said, you can put a gas mask to ignore
the room full of toxic gas, but that doesn't solve the gas problem in
itself, you're just denyinng it exists. Then someday you forget about
it, remove the mask, and suffocate.
Jeremie
That's what NPEs are! They're a *symptom* of you passing crap in to
fields or functions. They very, VERY rarely actually point out what the
underlying mistake is.
There again, I favor stronger initialization semantics over nonnull
types. This will get rid of most of these errors and still keep you on
your toes when a segfault arise, if you only see a segfault once a year
how will you know how to handle it :)
Most segfaults I have take me at most a few minutes to pinpoint. Its
finding backdoors to compiler enforcements thats annoying.
