Leandro Lucarella wrote:
> That's not an exception!!!! What's the point of that????  Why don't you
> just write a library function like like enforce but that uses exit(1)
> instead of throwing an exception for that?!?!?! You really want to
> sacrifice the correct behavior for this dumb, dumb "feature"???
> This really makes me mad! God...

Relax, we're all on the same boat. To answer each question in sequence:

1. The point of that is to terminate the program if the number of arguments passed is not satisfactory.

2. I don't write a library function like enforce that uses exit(1) because:

2.1. I'd have to write a ton of them.

2.2. I don't want to exit(1), I want to correctly propagate an exception. In this particular case it would exit straight out of main so it's the same as exit(1) but many scripts have more than one function.

3. I don't want to sacrifice correct behavior for anything in particular. It is your view that the behavior you like is correct and the one I like is incorrect.

> Plus *ANY* other programming language mark uncaught exceptions as
> OBVIOUS ERRORS (they print traces or abort()).

Not Perl for example. I don't know whether Java prints the stack by default or not.


Andrei

Leandro Lucarella wrote:
>> 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.
> 
> Calling abort() on Linux will simply print "Aborted". Do you think is that bad that worth being completely different than any other PL and making debug an uncaught exception almost imposible???

What is impossible about writing one try statement?

Andrei

Michel Fortin wrote:
> Le 2010-07-30 ? 1:01, Andrei Alexandrescu a ?crit :
> 
>> Exception messages are meant to be seen by users.
> 
> I disagree.
> 
> The error message of an exception might be meaningful in a small program that does only one thing at a time, but in general to give the user an understandable error message you need more context information.

I agree. That doesn't make the exception's own message unneeded or unnecessary. It should be at most embellished.

> So I believe in the vast majority of cases calling abort() and
> showing a stack trace is what you want. That's what most other
> languages do. It's easy to get what Andrei wants with a "try {...}
> catch (Exception e) { writeln(e); exit(-1); }" in the main, but I'd
> generally recommend against this.

It's not that I want. It's an important use of the language. You could argue that D should not attempt to attempt scripting, but I think it should. That implies an ability to write short programs that do useful things.


Andrei

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

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

And it's not just Python. PHP 5 too shows the stack trace for uncaught exceptions.

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

On Fri, 30 Jul 2010, Andrei Alexandrescu wrote:

> It's not that I want. It's an important use of the language. You could argue that D should not attempt to attempt scripting, but I think it should. That implies an ability to write short programs that do useful things.
> 
> 
> Andrei

It's worth noting that you're changing the definition of the language away from it's a Systems Programming language and using that as an argument to change behavior.

I don't disagree with the desire to make short simple apps easy to both write and read.  I'm not sure I agree with the requirement to not emit anything but the exception's message on an escaping exception.

I've never, in any language that I've used that has exceptions -- admitedly not many, considered exceptions to be part of the user of the apps experience.  They're internal mechanisms.

That said, D has upturned a lot of older thinking and styles, and this might well be one of the ones worth changing.  I'm not convinced yet.


Later,
Brad

Le 2010-07-30 ? 20:37, Andrei Alexandrescu a ?crit :

> Not Perl for example. I don't know whether Java prints the stack by default or not.

Java does print a stack trace. Same for Objective-C.

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

On Friday, July 30, 2010 18:02:48 Brad Roberts wrote:
> On Fri, 30 Jul 2010, Andrei Alexandrescu wrote:
> > It's not that I want. It's an important use of the language. You could argue that D should not attempt to attempt scripting, but I think it should. That implies an ability to write short programs that do useful things.
> > 
> > 
> > Andrei
> 
> It's worth noting that you're changing the definition of the language away from it's a Systems Programming language and using that as an argument to change behavior.
> 
> I don't disagree with the desire to make short simple apps easy to both write and read.  I'm not sure I agree with the requirement to not emit anything but the exception's message on an escaping exception.
> 
> I've never, in any language that I've used that has exceptions -- admitedly not many, considered exceptions to be part of the user of the apps experience.  They're internal mechanisms.
> 
> That said, D has upturned a lot of older thinking and styles, and this might well be one of the ones worth changing.  I'm not convinced yet.

I tend to agree that users should never see exceptions. I would expect uncaught exceptions (other than unrecoverable ones like out of memory) to be logic errors in the code, not a means of error reporting to the user. I guess that I kind of get where Andrei is coming from though. But personally, I don't see all that big a deal in having the exception printed out in such cases. It's useful for debugging purposes, and if it's being used by someone other than the developer, it could still be useful for bug reporting purposes. Certainly, for what _I_ do, I'd prefer to have the stack trace printed.

Perhaps whether the stack trace is printed should be based on whether the code was compiled in release mode, or maybe dmd should print a stack trace and rdmd shouldn't (though I don't know how much they share and how feasible it would be for them to act differently).

For what it's worth, Java prints a stack trace for uncaught exceptions. It certainly seems that at least some there are a number of languages out there that decided that it was appropriate to print a stack trace for uncaught exceptions.

- Jonathan M Davis

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

I said that in several mails before, but it looks like you choose to ignore them.  Not only Python, most PL do that:

Lua: http://codepad.org/l85PabyG
PHP: http://codepad.org/aYsLHAZi
Ruby: http://codepad.org/Wt3tPcvm

I think Java and C# too (to count a few compiled languages), but
I dont't have a compiler to test and codepad doesn't support them :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Don't take life to seriously, you won't get out alive

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

http://bradrants.com/blog/uploaded/BradRants/Images/Misc/WhatYouTalkinBoutWillis.jpg

Seriously, you're COMPLETELY WRONG! See my other e-mail.

Reality is against you on this one. Please, please come into reason.


-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
una vez mas voy a arrastrar mi alma por el suelo
y no me importa sentirme mal, si es lo que quiero
tragando polvo, llorando sangre, anocheciendo
una vez mas voy a cerrar mis ojos para siempre

Le 2010-07-30 ? 20:38, Andrei Alexandrescu a ?crit :

> Leandro Lucarella wrote:
>> Calling abort() on Linux will simply print "Aborted". Do you think is that bad that worth being completely different than any other PL and making debug an uncaught exception almost imposible???
> 
> What is impossible about writing one try statement?

If you have a debugger hooked, abort() will cause the debugger to stop the program in the state it currently is. If an uncaught exception doesn't unwind the stack and instead calls abort(), the debugger will stop the program exactly in the state the exception was thrown, not in a state where everything has been cleaned up and no clues as to what happened are left.

It's like in the real world if you see a crime happen: don't clean up before calling the police, I guaranty the inspector won't appreciate. An uncaught exception is an error not expected by the programmer, it requires investigation to ensure the program's correctness. This investigation might not be worth it if it happens in a simple script, but to help debug a big program you shouldn't unwind the stack before calling abort().

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