Yeah, with both.  The only change is the addition of a foretold if ulimit is nonzero.

Sent from my iPhone

On Jul 30, 2010, at 7:54 AM, Steve Schveighoffer <schveiguy at yahoo.com> wrote:

> 
> 
> 
> 
> ----- Original Message ----
>> From: Sean Kelly <sean at invisibleduck.org>
>> To: Discuss the phobos library for D <phobos at puremagic.com>
>> Sent: Fri, July 30, 2010 10:46:38 AM
>> Subject: Re: [phobos] Calling abort() on unhandled exception
>> 
>> That's the thing.  With Leandro's proposed behavior, the stack isn't  unwound because the exception is effectively never caught.  The runtime can  still print the error message like it does now, it just works as if from a  signal handler.
>> 
> 
> With stack trace?  I'd much rather have a stack trace than a core file.  A stack trace can easily be read, is easy to email/attach to a bug report, and does not require duplicating the entire environment to use.
> 
> -Steve
> 
> 
> 
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Steve Schveighoffer, el 30 de julio a las 07:54 me escribiste:
> > From: Sean Kelly <sean-m2zzWtmgR3jd0EmSfiOO99i2O/JbrIOy at public.gmane.org>
> > To: Discuss the phobos library for D <phobos-4o3eaN+cb9R8UrSeD/g0lQ at public.gmane.org>
> > Sent: Fri, July 30, 2010 10:46:38 AM
> > Subject: Re: [phobos] Calling abort() on unhandled exception
> > 
> > That's the thing.  With Leandro's proposed behavior, the stack isn't  unwound
> >because the exception is effectively never caught.  The runtime can  still print the error message like it does now, it just works as if from a  signal handler.
> >
> 
> With stack trace?  I'd much rather have a stack trace than a core file.  A stack trace can easily be read, is easy to email/attach to a bug report, and does not require duplicating the entire environment to use.


Why this is SO hard to understand. Please, read it carefully:

abort() != core dump
abort() != not printing a stack trace

You can have it all. You can print just an error message as Walter and
Andrei wants (which I think is just sick), you can print a stack trace
as you want (the same for me, I don't mind it) and *after* that, call
abort() (this is the only thing I care about).

The let the OS do with the abort() whatever it want to do with it.
abort() *will* raise(SIGABRT) if the runtime is C99 (and POSIX)
compilant. That's the only thing guaranteed. On Linux, most
distributions are configured by default with ulimit -c 0, which WON'T
DUMP A CORE. You can enable core dumping by increasing the ulimit.

If you run the program from a debugger (at least GDB), the SIGABRT will be caught by the debugger and will let you inspect the program at the exact point the uncaught exception was thrown (regardless of whatever you ulimit -c value is).

Please, confirm that you understand this and then let's have a meaningful discussion.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Your success is measured by your ability to finish things

Steve Schveighoffer wrote:
> Um, no.  Exceptions can easily be uncaught (oops, forgot a try catch!).  I don't want the end result of an uncaught exception to be a bug that's impossible or difficult to determine because no stack trace was printed.  Let's consider that an exception may not be easily repeated and is most likely encountered by a user, not a developer.  Giving a mechanism to communicate the problem as completely as possible from the user developer should be the default.
> 
> We should classify any exception or error that gets thrown outside of main to be an exception that was not planned for by the developer, and therefore a program error.  This should trigger as much info as possible, definitely including a stack trace, and possibly a core dump (though, dumping core after catching an exception is next to useless).
> 
> If you want to avoid printing stack traces, catch the exception inside of main. I don't think it's too much to ask.

That argument goes both ways, i.e. I could tell you it's not much to ask to insert a try/catch if you care about the stack trace.

It comes back to doing a sensible thing by default. main() without a try/catch is common in short scripts. I am currently _exceedingly_ happy that I'm able to write 10-line scripts that do something interesting and behave reasonably in all circumstances. Obviously, a stack trace is not something anyone would be interested in for a short script. You are saying that I should take a size hit in order to protect you from adding 6 lines to a 100,000 lines program.

D should be script-friendly, it's a huge boon and a huge appeal, and stack traces don't go with script friendliness. Serious programs can afford the slight overhead.

See my point?


Andrei

Sean Kelly, el 30 de julio a las 07:42 me escribiste:
> On Jul 29, 2010, at 10:01 PM, Andrei Alexandrescu wrote:
> > 
> > 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.
> 
> Fair enough.  Maybe they should only be displayed for Errors, not Exceptions?

No, it's not fair enough, that code is wrong, wrong, wrong. There is no reason not to call exit(1) for handling that kind of errors.

If you *REALLY REALLY* want some kind of exception to be caught by main and just print a nice message, make it explicit. Add a standard exception, like UserErrorException, and catch only *that* exception, not *ANY* exception. Then Andrei can be happy and write horrible code that throws a UserErrorException instead of using exit().

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
A veces quisiera ser un auto,
para chocar como choco siendo humano,
para romperme en mil pedazos.

What's wrong with stack traces in short scripts?  I use D all the time for short (< a few hundred lines) scripts and sometimes I use Python instead when I need a library that's not easily available in D or need to share my code with Python hackers.  I honestly prefer Python's "always print a stack trace" to D's "make me fire up a debugger" for anything over ~50 lines (the point where I start to use functions instead of just writing all my code inline in main()).

On Fri, Jul 30, 2010 at 11:52 AM, Andrei Alexandrescu <andrei at erdani.com>wrote:

> Steve Schveighoffer wrote:
>
>> Um, no.  Exceptions can easily be uncaught (oops, forgot a try catch!).  I
>> don't want the end result of an uncaught exception to be a bug that's
>> impossible or difficult to determine because no stack trace was printed.
>>  Let's consider that an exception may not be easily repeated and is most
>> likely encountered by a user, not a developer.  Giving a mechanism to
>> communicate the problem as completely as possible from the user developer
>> should be the default.
>>
>> We should classify any exception or error that gets thrown outside of main to be an exception that was not planned for by the developer, and therefore a program error.  This should trigger as much info as possible, definitely including a stack trace, and possibly a core dump (though, dumping core after catching an exception is next to useless).
>>
>> If you want to avoid printing stack traces, catch the exception inside of main.  I don't think it's too much to ask.
>>
>
> That argument goes both ways, i.e. I could tell you it's not much to ask to insert a try/catch if you care about the stack trace.
>
> It comes back to doing a sensible thing by default. main() without a try/catch is common in short scripts. I am currently _exceedingly_ happy that I'm able to write 10-line scripts that do something interesting and behave reasonably in all circumstances. Obviously, a stack trace is not something anyone would be interested in for a short script. You are saying that I should take a size hit in order to protect you from adding 6 lines to a 100,000 lines program.
>
> D should be script-friendly, it's a huge boon and a huge appeal, and stack traces don't go with script friendliness. Serious programs can afford the slight overhead.
>
> See my point?
>
>
> Andrei
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100730/07ba4dca/attachment.html>

What's hard about using something other than exceptions to print usage in short scripts?

This looks just as readable/easy to me:

import std.usage;

int main(string[] args)
{
   checkUsage(args.length > 1, "Usage: prog args");
   ....
}

I also would like to see stack traces in small scripts too, esp. when the script isn't throwing the exception.

-Steve



----- Original Message ----
> From: Andrei Alexandrescu <andrei at erdani.com>
> To: Discuss the phobos library for D <phobos at puremagic.com>
> Sent: Fri, July 30, 2010 11:52:33 AM
> Subject: Re: [phobos] Calling abort() on unhandled exception
> 
> Steve Schveighoffer wrote:
> > Um, no.  Exceptions can easily be  uncaught (oops, forgot a try catch!).  I
>don't want the end result of an  uncaught exception to be a bug that's impossible or difficult to determine  because no stack trace was printed.  Let's consider that an exception may  not be easily repeated and is most likely encountered by a user, not a  developer.  Giving a mechanism to communicate the problem as completely as  possible from the user developer should be the default.
> > 
> > We  should classify any exception or error that gets thrown outside of main
>to be an  exception that was not planned for by the developer, and therefore a program  error.  This should trigger as much info as possible, definitely including  a stack trace, and possibly a core dump (though, dumping core after catching an  exception is next to useless).
> > 
> > If you want to avoid printing  stack traces, catch the exception inside of
>main.  I don't think it's too  much to ask.
> 
> That argument goes both ways, i.e. I could tell you it's not  much to ask to
>insert a try/catch if you care about the stack trace.
> 
> It  comes back to doing a sensible thing by default. main() without a try/catch
>is  common in short scripts. I am currently _exceedingly_ happy that I'm able to write 10-line scripts that do something interesting and behave reasonably in all circumstances. Obviously, a stack trace is not something anyone would be interested in for a short script. You are saying that I should take a size hit in order to protect you from adding 6 lines to a 100,000 lines program.
> 
> D  should be script-friendly, it's a huge boon and a huge appeal, and stack
>traces  don't go with script friendliness. Serious programs can afford the slight  overhead.
> 
> See my  point?
> 
> 
> Andrei
> _______________________________________________
> phobos  mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
> 

Calm down :)  I don't know anything about stack traces, I thought you could not know the stack trace until you unwound the stack.  If that's not true, then excuse my ignorance, and by all means, call abort at the point the exception is thrown after printing a stack trace.

BTW, for some reason I just received 4 of your messages (including some dated 3 hours ago) about 2 minutes ago.  So I wasn't exactly ignoring your posts ;)

-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: Fri, July 30, 2010 11:45:24 AM
> Subject: Re: [phobos] Calling abort() on unhandled exception
> 
> 
> 
> Steve Schveighoffer, el 30 de julio a las 07:54 me escribiste:
> >  > From: Sean Kelly <sean-m2zzWtmgR3jd0EmSfiOO99i2O/JbrIOy at public.gmane.org>
> >  > To: Discuss the phobos library for D
><phobos-4o3eaN+cb9R8UrSeD/g0lQ at public.gmane.org>
> > >  Sent: Fri, July 30, 2010 10:46:38 AM
> > > Subject: Re: [phobos] Calling  abort() on unhandled exception
> > > 
> > > That's the  thing.  With Leandro's proposed behavior, the stack isn't
>unwound
>
> > >because the exception is effectively never caught.  The  runtime can  still
>print
>
> > >the error message like it does now,  it just works as if from a  signal
>handler.
> > >
> > 
> >  With stack trace?  I'd much rather have a stack trace than a core  file.  A
>stack
>
> > trace can easily be read, is easy to email/attach  to a bug report, and does
>not
>
> > require duplicating the entire  environment to use.
> 
> 
> Why this is SO hard to understand. Please, read  it carefully:
> 
> abort() != core dump
> abort() != not printing a stack  trace
> 
> You can have it all. You can print just an error message as Walter  and
> Andrei wants (which I think is just sick), you can print a stack  trace
> as you want (the same for me, I don't mind it) and *after* that,  call
> abort() (this is the only thing I care about).
> 
> The let the OS do  with the abort() whatever it want to do with it.
> abort() *will*  raise(SIGABRT) if the runtime is C99 (and POSIX)
> compilant. That's the only  thing guaranteed. On Linux, most
> distributions are configured by default with  ulimit -c 0, which WON'T
> DUMP A CORE. You can enable core dumping by  increasing the ulimit.
> 
> If you run the program from a debugger (at least  GDB), the SIGABRT will be caught by the debugger and will let you inspect the  program at the exact point the uncaught exception was thrown (regardless of  whatever you ulimit -c value is).
> 
> Please, confirm that you understand  this and then let's have a meaningful discussion.
> 
> -- 
> Leandro  Lucarella (AKA luca)                       http://llucax.com.ar/
> ----------------------------------------------------------------------
> GPG  Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A  8D05)
> ----------------------------------------------------------------------
> Your  success is measured by your ability to finish  things
> 
> _______________________________________________
> phobos mailing  list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
> 

On Friday, July 30, 2010 09:41:56 Steve Schveighoffer wrote:
> Calm down :)  I don't know anything about stack traces, I thought you could not know the stack trace until you unwound the stack.  If that's not true, then excuse my ignorance, and by all means, call abort at the point the exception is thrown after printing a stack trace.

You can get at the stack trace in the core dump with gdb. It's just way more of a pain than getting it when it's printed to the console. It's actually pretty amazing how much stuff is sitting in a core dump. Personally, I generally don't care about having anywhere near that much info, or if I do, I'd rather be debugging the program directly, but there is quite a lot of useful info there, and the stack trace is definitely on the list.

- Jonathan M Davis

Le 2010-07-30 ? 11:29, Sean Kelly a ?crit :

> Another alternative is deriving all exceptions that shouldn't show a trace by default from an exception with a custom toString that omits this info.

I think we already have one: the OwnerTermianted exception. We could use another "normal termination" exception meant to terminate the program. The advantage over calling exit(-1) directly is that it'll honor destructors, finally clauses, and scope(exit) statements.

Upon catching this exception at main()'s termination, the runtime could print its message but omit the stack trace.



-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

Le 2010-07-30 ? 11:52, Andrei Alexandrescu a ?crit :

> Steve Schveighoffer wrote:
>> If you want to avoid printing stack traces, catch the exception inside of main.  I don't think it's too much to ask.
> 
> That argument goes both ways, i.e. I could tell you it's not much to ask to insert a try/catch if you care about the stack trace.

Calling abort() before unwinding the stack also has the advantage that if you have a debugger hooked it'll stop you right there and you'll have the full state of the program available at the moment the exception was thrown *before* unwinding the stack.


> D should be script-friendly, it's a huge boon and a huge appeal,

That's true.

> and stack traces don't go with script friendliness.

I disagree. Stack traces can be useful when debugging a script. Imagine your 10-line script uses a library that has a bug in it, and all you get is the message from an exception thrown by a function from another library used by that first library. Without a stack trace you're totally lost.

If you want to throw error messages to the user using the exception mechanism, then there could be a special exception class for that. But normal exceptions aren't things that should be seen by the user; and if the user sees them he'll probably seek your help and the first thing you'll want is to know in what context the exception was thrown: a stack trace and if necessary a debugger stopped right where it happened.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/