• Bartosz Milewski <bartosz-nospam relisoft.com> Feb 09 2009
• Christopher Wright <dhasenan gmail.com> Feb 11 2009
• Jarrett Billingsley <jarrett.billingsley gmail.com> Feb 11 2009

Bartosz Milewski <bartosz-nospam relisoft.com> writes:

What bothers me is that this is equivalent to saying that a seg fault caused by
null dereference can be caught only if the programmer puts explicit runtime
checks before it happens. I would say that reaks of C philosophy, except that
in most C++ implementation I've been working with you can simply catch a seg
fault. I wouldn't mind not being able to catch a seg fault in a language where
it's impossible to have an unitialized reference. But both in Java and in D
it's very easy to get into this situation (in fact, it's easier in D) because
of hidden reference semantics of class objects. Which ties nicely with the
discussion of nullable types.

Christopher Wright Wrote:

 Denis Koroskin wrote:
 On Mon, 09 Feb 2009 11:24:09 +0300, Bartosz Milewski 
 <bartosz relisoft.com> wrote:
 
 My point is that it's a redundant check. Whether it is there or not, 
 the result is the same--the program will halt. Maybe the error message 
 form enforce will look nicer, but that's about it.


 It will throw a recoverable Exception (an access violation is an Error, 
 IIRC).


 And a segfault is a hard stop, unless you have a signal handler for it.

Christopher Wright <dhasenan gmail.com> writes:

Bartosz Milewski wrote:
 What bothers me is that this is equivalent to saying that a seg fault caused
by null dereference can be caught only if the programmer puts explicit runtime
checks before it happens. I would say that reaks of C philosophy, except that
in most C++ implementation I've been working with you can simply catch a seg
fault. I wouldn't mind not being able to catch a seg fault in a language where
it's impossible to have an unitialized reference. But both in Java and in D
it's very easy to get into this situation (in fact, it's easier in D) because
of hidden reference semantics of class objects. Which ties nicely with the
discussion of nullable types.


That is annoying, and there are libraries that fix it. It's already 
handled on Windows by default; why isn't it handled on Linux?

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Wed, Feb 11, 2009 at 8:19 AM, Christopher Wright <dhasenan gmail.com> wrote:
 Bartosz Milewski wrote:
 What bothers me is that this is equivalent to saying that a seg fault
 caused by null dereference can be caught only if the programmer puts
 explicit runtime checks before it happens. I would say that reaks of C
 philosophy, except that in most C++ implementation I've been working with
 you can simply catch a seg fault. I wouldn't mind not being able to catch a
 seg fault in a language where it's impossible to have an unitialized
 reference. But both in Java and in D it's very easy to get into this
 situation (in fact, it's easier in D) because of hidden reference semantics
 of class objects. Which ties nicely with the discussion of nullable types.


 That is annoying, and there are libraries that fix it. It's already handled
 on Windows by default; why isn't it handled on Linux?


Probably because on Windows, segfaults are reported through the same
exception handling mechanism that the D compiler makes use of, while
on linux, they come in through signal handlers.  I don't know how easy
it is to start unwinding (or completely unwind) the call stack in the
signal handler but the impression I get is that it's not fun.