Walter Bright wrote:
> I think we misunderstand each other. A file copy program that fails due to, say, the disk being full, should not produce a core dump. It should produce an error message like:
> 
>   error: disk full
> 
> An uncaught exception is NOT an invalid or crashed program in D.

I think Sean talks about Throwable objects that are not Exception objects.

Andrei

Andrei Alexandrescu, el 29 de julio a las 19:51 me escribiste:
> Walter Bright wrote:
> >I think we misunderstand each other. A file copy program that fails due to, say, the disk being full, should not produce a core dump. It should produce an error message like:
> >
> >  error: disk full
> >
> >An uncaught exception is NOT an invalid or crashed program in D.
> 
> I think Sean talks about Throwable objects that are not Exception objects.

I think (and hope) he talks about bug 4385.

Please, please, please, pretty please, call abort() at least on Linux, is what every Linux programmer expects, I find debugging an accidentally uncaught exception in D almost impossible.

Is not that bad for lazy people either, just add 4 lines to you main:

try {
// program
} catch (Exception e) {
        writeln(e);
}

Or whatever. Add a library function or an optional exception handler for people wanting to shadow exceptions and make it look like a normal termination.

BTW, *most Linux distributions don't dump cores by default* (you have to
change the ulimit to enable that feature, but if you run the program
inside a debugger, you'll get the exact backtrace where the exception
was originally thrown), so this doesn't mean that programs will be
dumping cores all over the places. I think part of the confusion about
implying that calling abort() will dump a core is because the title of
the bug report is incorrect, what I meant was uncaught exceptions should
call abort() (and I'm changing it right now). The runtime will probably
print just "Aborted" by that is triggered by SIGABRT, not abort(). So in
a common Linux distribution, a D program that exited because an uncaught
exception will just print (no core generated):
error: disk full
Aborted
Which seems reasonable.

Please also note that almost *ALL* programming languages treats uncaught exception as errors and not normal program termination, most even print a stack trace to show is a programming error.

[1] http://d.puremagic.com/issues/show_bug.cgi?id=4385

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
EXPOSICION INTERNACIONAL DE INODOROS
	-- Cr?nica TV

Andrei Alexandrescu wrote:
> Walter Bright wrote:
>> I think we misunderstand each other. A file copy program that fails due to, say, the disk being full, should not produce a core dump. It should produce an error message like:
>>
>>   error: disk full
>>
>> An uncaught exception is NOT an invalid or crashed program in D.
>
> I think Sean talks about Throwable objects that are not Exception objects.
>

It's reasonable for seg fault exceptions to produce a core dump. It isn't for recoverable Exceptions, or for non-recoverable ones like out of memory.

Michel Fortin, el 29 de julio a las 22:26 me escribiste:
> Le 2010-07-29 ? 21:52, Sean Kelly a ?crit :
> 
> > Huh, so the ObjC behavior is to print the exception and abort() too.
> 
> Mostly. Actually, it seems it calls the C++ runtime's std::terminate, which in turns call a user-settable handler function which is abort() if you haven't changed it.

GCC uses a custom termination handler that prints the exception and then calls abort(), see: http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt02ch06s02.html

> > Looks like good justification for doing it in D as well then.
> 
> 
> I think it's the right thing to do, for OSX at least.

In Linux too, and probably any POSIX compatible OS.

> Perhaps it could be useful if the programmer could substitute his own handler function (similar to what you can do with std::set_terminate in C++) if he wants to do something special (such as a core dump).

abort() will dump a core if you set ulimit for core size bigger than
what the core of your program is. Try this (using sh/bash):
$ ulimit -c unlimited
$ sleep 60 &
$ kill -ABRT $!

You will get a core. Or just try running it from GDB without setting ulimit, you'll get to inspect the program exactly where it was interrupted by the signal.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Y2K
<Aztech_> hmm, nothing major has happend, what an anticlimax
<CaPS> yeah
<CaPS> really sucks
<CaPS> I expected for Australia to sink into the sea or something
<CaPS> but nnoooooooo

On Jul 29, 2010, at 8:21 PM, Walter Bright wrote:
> 
> Andrei Alexandrescu wrote:
>> Walter Bright wrote:
>>> I think we misunderstand each other. A file copy program that fails due to, say, the disk being full, should not produce a core dump. It should produce an error message like:
>>> 
>>>  error: disk full
>>> 
>>> An uncaught exception is NOT an invalid or crashed program in D.
>> 
>> I think Sean talks about Throwable objects that are not Exception objects.
>> 
> 
> It's reasonable for seg fault exceptions to produce a core dump. It isn't for recoverable Exceptions, or for non-recoverable ones like out of memory.

At the moment, we don't differentiate between seg faults and non-recoverable errors.  Though seg faults are only thrown as exceptions on Windows which doesn't have core dumps anyway, as far as I know. For what it's worth, I was investigating this bug:

http://d.puremagic.com/issues/show_bug.cgi?id=4385

Sean Kelly wrote:
> On Jul 29, 2010, at 8:21 PM, Walter Bright wrote:
>> Andrei Alexandrescu wrote:
>>> Walter Bright wrote:
>>>> I think we misunderstand each other. A file copy program that fails due to, say, the disk being full, should not produce a core dump. It should produce an error message like:
>>>>
>>>>  error: disk full
>>>>
>>>> An uncaught exception is NOT an invalid or crashed program in D.
>>> I think Sean talks about Throwable objects that are not Exception objects.
>>>
>> It's reasonable for seg fault exceptions to produce a core dump. It isn't for recoverable Exceptions, or for non-recoverable ones like out of memory.
> 
> At the moment, we don't differentiate between seg faults and non-recoverable errors.  Though seg faults are only thrown as exceptions on Windows which doesn't have core dumps anyway, as far as I know. For what it's worth, I was investigating this bug:
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=4385

I see. Overall, my opinion is that regular exceptions that escape main(0 should simply print their error message to stderr and exit(1). There should be no stack trace, abort(), core dump, or anything worse than that. Print the string and exit(1). Anything more will force most people to actually insert a try/catch in main to do the simple thing.

Andrei

On Jul 29, 2010, at 9:37 PM, Andrei Alexandrescu wrote:

> Sean Kelly wrote:
>> On Jul 29, 2010, at 8:21 PM, Walter Bright wrote:
>>> Andrei Alexandrescu wrote:
>>>> Walter Bright wrote:
>>>>> I think we misunderstand each other. A file copy program that fails due to, say, the disk being full, should not produce a core dump. It should produce an error message like:
>>>>> 
>>>>> error: disk full
>>>>> 
>>>>> An uncaught exception is NOT an invalid or crashed program in D.
>>>> I think Sean talks about Throwable objects that are not Exception objects.
>>>> 
>>> It's reasonable for seg fault exceptions to produce a core dump. It isn't for recoverable Exceptions, or for non-recoverable ones like out of memory.
>> At the moment, we don't differentiate between seg faults and non-recoverable errors.  Though seg faults are only thrown as exceptions on Windows which doesn't have core dumps anyway, as far as I know. For what it's worth, I was investigating this bug:
>> http://d.puremagic.com/issues/show_bug.cgi?id=4385
> 
> I see. Overall, my opinion is that regular exceptions that escape main(0 should simply print their error message to stderr and exit(1). There should be no stack trace, abort(), core dump, or anything worse than that. Print the string and exit(1). Anything more will force most people to actually insert a try/catch in main to do the simple thing.

I think the stack trace at least should remain.  People have been begging for that for years, and I do think it's pretty useful.  Simply printing an error message says nothing about the context, and it's context that gives error messages meaning.

As for core dumps, if the user wants them for unhandled exceptions rather than just segfaults, there's currently no way to get them with a D app because main() catches everything.  I'm not sure about the merit of failing via abort() vs. returning -1, but I do think it's a nice option to have available.  Personally... I dunno.  I'd mostly want them for segfaults and bus errors, and I can do that with signal handlers.  I'd have to defer to someone else on that.

Sean Kelly wrote:
> On Jul 29, 2010, at 9:37 PM, Andrei Alexandrescu wrote:
> 
>> Sean Kelly wrote:
>>> On Jul 29, 2010, at 8:21 PM, Walter Bright wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> Walter Bright wrote:
>>>>>> I think we misunderstand each other. A file copy program that fails due to, say, the disk being full, should not produce a core dump. It should produce an error message like:
>>>>>> 
>>>>>> error: disk full
>>>>>> 
>>>>>> An uncaught exception is NOT an invalid or crashed program
>>>>>>  in D.
>>>>> I think Sean talks about Throwable objects that are not Exception objects.
>>>>> 
>>>> It's reasonable for seg fault exceptions to produce a core dump. It isn't for recoverable Exceptions, or for non-recoverable ones like out of memory.
>>> At the moment, we don't differentiate between seg faults and
>>> non-recoverable errors.  Though seg faults are only thrown as
>>> exceptions on Windows which doesn't have core dumps anyway, as
>>> far as I know. For what it's worth, I was investigating this bug:
>>>  http://d.puremagic.com/issues/show_bug.cgi?id=4385
>> I see. Overall, my opinion is that regular exceptions that escape
>> main(0 should simply print their error message to stderr and
>> exit(1). There should be no stack trace, abort(), core dump, or
>> anything worse than that. Print the string and exit(1). Anything
>> more will force most people to actually insert a try/catch in main
>>  to do the simple thing.
> 
> I think the stack trace at least should remain. People have been begging for that for years, and I do think it's pretty useful. Simply printing an error message says nothing about the context, and it's context that gives error messages meaning.

I for one really enjoy stuff like:

void main(string[] args)
{
     enforce(args.length > 1, "Usage: prog arg");
     ...
}

Having a stack trace tacked there... not good. Exception messages are meant to be seen by users. Stack traces are meant to be seen by the programmer. The fact that we print both by default doesn't sit well at all.

> As for core dumps, if the user wants them for unhandled exceptions
> rather than just segfaults, there's currently no way to get them with
>  a D app because main() catches everything.

Well we need to do something about that.

> I'm not sure about the
> merit of failing via abort() vs. returning -1, but I do think it's a
>  nice option to have available.  Personally... I dunno.  I'd mostly
> want them for segfaults and bus errors, and I can do that with signal
>  handlers.  I'd have to defer to someone else on that.

Is it reasonable to say that Exception is the "nicer" thing and Throwable is the "less nice" thing that is handled differently? Then come bus errors, which are "not nice at all".


Andrei

I agree with Andrei on that. But I'd prefer a severity field in a single exception class instead of a bunch of randomly named classes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100730/3ee6579b/attachment.html>

Wouldn't this be useless?  That is, do you care about a core dump when the stack is unwound (and the source of the problem is gone from the stack)?

If this is all you want, why not write your main that way?

BTW, my opinion is that an uncaught exception should not dump core.  It should print a stack trace and exit with non-zero exit code.  I understand the reasoning behind it, but dumping core is not a normal mode of operation for most users.  They don't know what to do with a core file, and silently dumping core on a system where one is not expecting it can fill up a filesystem.

-Steve



----- Original Message ----
> From: Leandro Lucarella <luca at llucax.com.ar>
> To: Discuss the phobos library for D
><public-phobos-4o3eaN+cb9R8UrSeD/g0lQ at plane.gmane.org>
> Sent: Thu, July 29, 2010 11:20:55 PM
> Subject: Re: [phobos] Calling abort() on unhandled exception
> 
> 
> 
> Andrei Alexandrescu, el 29 de julio a las 19:51 me escribiste:
> >  Walter Bright wrote:
> > >I think we misunderstand each other. A file  copy program that fails due to, say, the disk being full, should not  produce a core dump. It should produce an error message  like:
> > >
> > >  error: disk full
> > >
> >  >An uncaught exception is NOT an invalid or crashed program in D.
> > 
> > I think Sean talks about Throwable objects that are not Exception  objects.
> 
> I think (and hope) he talks about bug 4385.
> 
> Please,  please, please, pretty please, call abort() at least on Linux, is what every  Linux programmer expects, I find debugging an accidentally uncaught exception  in D almost impossible.
> 
> Is not that bad for lazy people either, just add  4 lines to you main:
> 
> try {
> // program
> } catch (Exception e)  {
>         writeln(e);
> }
> 
> Or whatever. Add a  library function or an optional exception handler for people wanting to  shadow exceptions and make it look like a normal termination.
> 
> BTW,  *most Linux distributions don't dump cores by default* (you have to
> change  the ulimit to enable that feature, but if you run the program
> inside a  debugger, you'll get the exact backtrace where the exception
> was originally  thrown), so this doesn't mean that programs will be
> dumping cores all over  the places. I think part of the confusion about
> implying that calling abort()  will dump a core is because the title of
> the bug report is incorrect, what I  meant was uncaught exceptions should
> call abort() (and I'm changing it right  now). The runtime will probably
> print just "Aborted" by that is triggered by  SIGABRT, not abort(). So in
> a common Linux distribution, a D program that  exited because an uncaught
> exception will just print (no core  generated):
> error: disk full
> Aborted
> Which seems  reasonable.
> 
> Please also note that almost *ALL* programming languages  treats uncaught exception as errors and not normal program termination, most  even print a stack trace to show is a programming error.
> 
> [1]  http://d.puremagic.com/issues/show_bug.cgi?id=4385
> 
> -- 
> Leandro  Lucarella (AKA luca)                       http://llucax.com.ar/
> ----------------------------------------------------------------------
> GPG  Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A  8D05)
> ----------------------------------------------------------------------
> EXPOSICION  INTERNACIONAL DE INODOROS
>     -- Cr?nica  TV
> 
> _______________________________________________
> phobos mailing  list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos