Steve Schveighoffer, el 30 de julio a las 09:41 me escribiste:
> Calm down :)

Yes, I know, know, I'm sorry, I got a little emotional with some absurd replies to this threads, yours were mostly reasonable :)

> 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 ;)

But in the mail you were responding saying that abort() == core dump, explicitly said that that wasn't true.

Anyway, I apology if I was rude :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Corr? muchas carreras, tratando de alcanzarte a vos.
Pero corr?a s?lo y siempre sal? ?ltimo.

Jonathan M Davis, el 30 de julio a las 10:22 me escribiste:
> 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.

Sometimes bugs are not that easy to reproduce, and having a core dump in those cases to inspect the dead program can be a life saver (talking out of experience). But again, calling abort() != dumping a core, it just give you the option.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Charles Chaplin once won 3rd price in a Charles Chaplin look-a-like contest

Michel Fortin, el 30 de julio a las 13:36 me escribiste:
> 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.

I agree that using an special exception for normal termination could be a good idea because of that (I even reported an enhancement asking for that[1]). But that's a whole other discussion.

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

That is perfectly fine with me.

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

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

Andrei Alexandrescu, el 30 de julio a las 08:52 me escribiste:
> 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.

Is clear that you don't understand the issue here. It's *IMPOSSIBLE* to get a stack trace in a debugger (i.e., a live stack trace) or a core dump that way.

So, yes, it way too much to ask :)

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

Not really.

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

----- 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 4:03:23 PM
> Subject: Re: [phobos] Calling abort() on unhandled exception
>
> But in the mail you were responding saying that  abort() == core dump, explicitly said that that wasn't true.

Well, technically I said that I'd rather not have a core dump (and especially when I thought core dumps and stack traces were mutually exclusive).  But you are right that I was implying that was going to be the default behavior.  I just remember back in my college days having my server quota filled up because of all the core dumps from my failed programs, and I thought of the poor user having his filesystem filled up by core dumps.

All is good, abort away, I think it's a fine idea.

-Steve

Michel Fortin wrote:
> 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.

Look at all scripts you've ever written or read. Scripts are not conceived to figure out a bug in a library. They are conceived to get something done quickly. If a script fails, you change it and try it again. Nobody writes a script expecting to debug a library with it.

Let me say that I just gave a talk at Google and presented a few short scripts that actually did something useful. People really warmed up to that. I think it's very important for D to stay script-friendly.

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

Scripts don't obey these needs. Is it really too much to ask that if you're writing a serious application you want to place a guard at main() level? I mean the marginal cost is virtually nil. Why hurt casual script users to save a few lines of a large application?


Andrei

Michel Fortin wrote:
> 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.

This doesn't work. A script could end with virtually any exception.

Andrei

Steve Schveighoffer wrote:
> 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.

Here's one example I used:

#!/usr/bin/env rdmd
import std.exception, std.file;
void main(string[] args) {
    enforce(args.length == 3,
       "Usage: trcopy file1 file2");
    auto tmp = args[2] ~ ".messedup";
    scope(failure) if (exists(tmp)) remove(tmp);
    copy(args[1], tmp);
    rename(tmp, args[2]);
}

It could end with at least a couple distinct exception types. Clearly we're not cutting the pie the right way. The right solution is - absent any handler, an exception leaking out of main() prints the message and exit(1).


Andrei

Steve Schveighoffer wrote:
> 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.

No scripting language ever behaves that way. They could if they wanted - they don't.

Andrei

David Simcha wrote:
> 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()).

I didn't know Python prints the stack trace on exception, so my previous argument just got destroyed :o).

Andrei