On 3/5/2012 11:51 AM, Jacob Carlborg wrote:
> Yeah, C and C++ might not do what's suggested but basically all other languages
> do it.


People turn to C and C++ for systems work and high performance.

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.

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.

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

On 3/5/2012 12:05 PM, Nick Sabalausky wrote:
> "Walter Bright"<newshound2@digitalmars.com>  wrote in message
> news:jiunst$qrm$1@digitalmars.com...
>>
>> 3. Intercepting and recovering from seg faults, div by 0, etc., all sounds
>> great on paper. In practice, it is almost always wrong. The only exception
>> (!) to the rule is when sandboxing a plugin (as you suggested).
>>
>
> The purpose of catching exceptions is to respond to a condition. Recovery is
> merely *one* such type of response.


Right, but Sandeep and I were specifically talking about recovering.

On 03/05/2012 05:39 AM, Adam D. Ruppe wrote:
> On Monday, 5 March 2012 at 03:24:32 UTC, Chad J wrote:
>> News to me. I've had bad runs with that back in the day, but maybe
>> things have improved a bit.
>
> Strangely, I've never had a problem with gdb and D,
> as far back as 2007.
> (at least for the basic stack trace kind of stuff).
>
> But, yeah, they've been improving a lot of things
> recently too.
>
>> Non-nullable types would be really cool right about now.
>
> Huh, I thought there was one in phobos by now.
>
> You could spin your own with something like this:
>
> struct NotNull(T) {
> T t;
> alias t this;
> @disable this();
> @disable this(typeof(null));
> this(T value) {
> assert(value !is null);
> t = value;
> }
>
> @disable typeof(this) opAssign(typeof(null));
> typeof(this) opAssign(T rhs) {
> assert(rhs !is null);
> t = rhs;
> return this;
> }
> }
>
>
> This will catch usages of the null literal at
> compile time, and other null references at runtime
> as soon as you try to use it.
>
> With the disabled default constructor, you are forced
> to provide an initializer when you use it, so no
> accidental null will slip in.
>
> The alias this means NotNull!T is substitutable for T,
> so you can drop it into existing apis.
>
>> It's that I simply cannot expect users to run my code in a debugger.
>
> :) I'm lucky if I can get more from my users than
> "the site doesn't work"!
>
>> The problem is that they don't help me when I missed a spot and didn't
>> use assertions, contracts, or invariants.
>
> Aye, I've had it happen. The not null types might help,
> though tbh I've never used anything like this in practice
> so maybe not. I don't really know.

This is quite close, but real support for non-nullable types means that they are the default and checked statically, ideally using data flow analysis.

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

On 04/03/12 04:34, Walter Bright wrote:
> On 3/3/2012 6:53 PM, Sandeep Datta wrote:
>>> It's been there for 10 years, and turns out to be a solution looking
>>> for a
>>> problem.
>>
>> I beg to differ, the ability to catch and respond to such asynchronous
>> exceptions is vital to the stable operation of long running software.
>>
>> It is not hard to see how this can be useful in programs which depend
>> on plugins
>> to extend functionality (e.g. IIS, Visual Studio, OS with drivers as
>> plugins
>> etc). A misbehaving plugin has the potential to bring down the whole
>> house if
>> hardware exceptions cannot be safely handled within the host
>> application. Thus
>> the inability of handling such exceptions undermines D's ability to
>> support
>> dynamically loaded modules of any kind and greatly impairs modularity.
>>
>> Also note hardware exceptions are not limited to segfaults there are
>> other
>> exceptions like division by zero, invalid operation, floating point
>> exceptions
>> (overflow, underflow) etc.
>>
>> Plus by using this approach (SEH) you can eliminate the software null
>> checks and
>> avoid taking a hit on performance.
>>
>> So in conclusion I think it will be worth our while to supply
>> something like a
>> NullReferenceException (and maybe NullPointerException for raw
>> pointers) which
>> will provide more context than a simple segfault (and that too without
>> a core
>> dump). Additional information may include things like a stacktrace (like
>> Vladimir said in another post) with line numbers, file/module names
>> etc. Please
>> take a look at C#'s exception hierarchy for some inspiration (not that
>> you need
>> any but it's nice to have some consistency across languages too). I am
>> just a
>> beginner in D but I hope D has something like exception chaining in C#
>> using
>> which we can chain exceptions as we go to capture the chain of events
>> which led
>> to failure.
>
> As I said, it already does that (on Windows). There is an access
> violation exception. Try it on windows, you'll see it.
>
> 1. SEH isn't portable. There's no way to make it work under non-Windows
> systems.
>
> 2. Converting SEH to D exceptions is not necessary to make a stack trace
> dump work.
>
> 3. Intercepting and recovering from seg faults, div by 0, etc., all
> sounds great on paper. In practice, it is almost always wrong. The only
> exception (!) to the rule is when sandboxing a plugin (as you
> suggested). Making such a sandbox work is highly system specific, and
> doesn't always fit into the D exception model (in fact, it never does
> outside of Windows).

Responding to traps is one of the very few examples I know of, where Windows got it completely right,
and *nix got it absolutely completely wrong. Most notably, the hardware is *designed* for floating point traps to be fully recoverable. It makes perfect sense to catch them and continue.
But unfortunately the *nix operating systems are completely broken in this regard and there's nothing we can do to fix them.

James Miller:

> 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.

In a normal program there are many situations where the programmer knows a class reference or a pointer can't be null. If the type system of the language allows you to write down this semantic information with some kind of annotation, and the compiler is able to analyze the code a bit to make that correct and handy, some null-related bugs don't happen. And this costs nothing at run-time (but maybe it increases the compilation time a bit).


> 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.

I agree. On the other hand null-related bugs are common enough and bad enough that improving their management in some way (helping avoid them, helping their debug) is more than just a little convenience.


> 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.

PHP is not at the top of the list of the languages for people that want "extreme safety".

Bye,
bearophile

On 03/06/2012 02:54 AM, Jacob Carlborg wrote:
> On 2012-03-06 08:53, Jacob Carlborg wrote:
>> On 2012-03-06 03:04, Steven Schveighoffer wrote:
>>> Certainly for Mac OS X, it should do the most informative appropriate
>>> thing for the OS it's running on. Does the above happen for D programs
>>> currently on Mac OS X?
>>
>> When an exception if thrown and uncaught it will print the stack trace
>> to in the terminal (if run in the terminal). If the program ends with a
>> segmentation fault the stack trace will be outputted to a log file.
>>
>
> Outputting to a log file is handle by the OS and not by druntime.
>

It sounds like what you'd want to do is walk the stack and print a trace to stderr without actually jumping execution.  Well, check for being caught first.  Once that's printed, then trigger an OS error and quit.

On 03/06/2012 03:27 AM, Walter Bright wrote:
> On 3/5/2012 11:51 AM, Jacob Carlborg wrote:
>> Yeah, C and C++ might not do what's suggested but basically all other
>> languages
>> do it.
>
>
> People turn to C and C++ for systems work and high performance.

Optional.  Flags.

If there is a truly unavoidable trade-off, then you give users CHOICE. Your opinion on this matter does not work well for /everyone/ in practice.

Not to mention that there seems to be a completely avoidable trade-off here.  A few posts have mentioned handlers in Linux that would work for printing traces, though not for recovery.  Seems kinda no-brainer.

I'd still want the /choice/ to incur higher runtime overhead to make null dereferences and maybe a few other obvious ones behave consistently with other exceptions in the language.  *I* would set this flag in a heartbeat; *you* don't have to.

Sandeep Datta:

> I am just going to leave this here...
> 
> *Fast Bounds Checking Using Debug Register*
> 
> http://www.ecsl.cs.sunysb.edu/tr/TR225.pdf

Is this idea usable in DMD to speed up D code compiled in non-release mode?

Bye,
bearophile