dereferencing null
Jacob Carlborg
doob at me.com
Tue Mar 6 02:53:19 PST 2012
On 2012-03-06 10:11, James Miller wrote:
> If you have a possible null, then check for it *yourself* sometimes
> you know its null, sometimes you don't have any control. However, the
> compiler has no way of knowing that. Its basically an all-or-nothing
> thing with the compiler.
If I know there is a possible null, then of course I check for it. But I
MAY NOT KNOW there is a possible null. People make mistakes, I make
mistakes. But I guess you just turn of exceptions and another error
handling completely because you never ever make a mistake.
> However, the compiler can (and I think does) warn of possible
> null-related errors. It doesn't fail, because, again, it can't be
> certain of what is an error and what is not. And it can't know, since
> that is the Halting Problem.
>
> I'm not sure what the fuss is here, we cannot demand that every little
> convenience be packed into D, at some point we need to face facts that
> we are still programming, and sometimes things go wrong. The best
> arguments I've seen so far is to install a handler that catches the
> SEGFAULT in linux, and does whatever SEH stuff it does in windows and
> print a stacktrace. If this happens in a long-running process, then,
> to be blunt, tough. Unless you're telling me that the only way to
> reproduce the bug is to run the program for the same amount of time in
> near-identical conditions, then sir, you fail at being a detective.
On Mac OS X the runtime would only need to catch any exception (as it
already does) and print the stack trace. But also re-throw the exception
to let the OS handle the logging of the exception (at least I hope that
will work).
> If you have a specific need for extreme safety and no sharp corners,
> use Java, or some other VM language, PHP comes to mind as well. If you
> want a systems programming language that is geared for performance,
> with modern convenience then stick around, do I have the language for
> you! Stop thinking in hypotheticals, because no language can cover
> every situation; "What if this is running in a space ship for 12 years
> and the segfault is caused by space bees?!" is not something we should
> be thinking about. If a process fails, then it fails, you try to
> figure out what happened (you do have logging on this mysterious
> program right?" then fix it.
>
> Its not easy, but if it was easy, we'd be out of jobs.
>
> </rant>
>
> --
> James Miller
--
/Jacob Carlborg
More information about the Digitalmars-d
mailing list