Skip Menu |
Report information
Id: 131877
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: szabgab [at] gmail.com
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



From: Gabor Szabo <szabgab [...] gmail.com>
Subject: better error message for exit("hello")
To: "rakudobug [...] perl.org" <rakudobug [...] perl.org>
Date: Thu, 10 Aug 2017 12:09:24 +0300
Download (untitled) / with headers
text/plain 509b
In Python one can pass a string to the exit() function that will be displayed and the program exited. In Perl 6 I get: $ perl6 To exit type 'exit' or '^D' Show quoted text
> exit("hello")
Cannot convert string to number: base-10 number must begin with valid digits or '.' in '⏏hello' (indicated by ⏏) in block <unit> at <unknown file> line 1 Would it be possible to special case when someone passes a string to exit and give a better error message telling how to write that? Better yet, could exit accept a string?
From: Joachim Durchholz <jo [...] durchholz.org>
Subject: Re: [perl #131877] better error message for exit("hello")
Date: Thu, 10 Aug 2017 11:47:15 +0200
To: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 767b
Show quoted text
> Would it be possible to special case when someone passes a string to > exit and give a better error message telling how to write that?
Maybe the error message should indicate what types are allowed. Show quoted text
> Better yet, could exit accept a string?
That would be equivalent to `print("hello");exit(0)`. Very little added value IMHO, but source of potential confusion: How will `exit($x)` use the content of `$x`, as a return code or as something to print? You have to check whether `$x` is an integer or not - and what about floating-point numbers? It could be converted to string or to int, and at least some programmers will expect the opposite of what Perl6 is doing. TL;DR it shouldn't accept a string, that would be worse than throwing an error. (IMHO etc.)
There's a little problem with it. You see, right now this works:

exit "1"

So we simply cannot force it to do something else with Strs because that can break existing (perfectly valid) code. We can go through a long deprecation cycle but it's not worth it (IMO).

But it may be possible to catch X::Str::Numeric exception and print better message for this situation… ¯\_(ツ)_/¯

On 2017-08-10 02:09:30, szabgab@gmail.com wrote:
Show quoted text
> In Python one can pass a string to the exit() function that will be
> displayed and the program exited.
>
>
> In Perl 6 I get:
>
> $ perl6
> To exit type 'exit' or '^D'
> > exit("hello")
> Cannot convert string to number: base-10 number must begin with valid
> digits or '.' in '⏏hello' (indicated by ⏏)
> in block <unit> at <unknown file> line 1
>
> Would it be possible to special case when someone passes a string to
> exit and give a better error message telling how to write that?
>
> Better yet, could exit accept a string?


Date: Thu, 10 Aug 2017 08:47:57 -0400
CC: Gabor Szabo <szabgab [...] gmail.com>
From: Brandon Allbery <allbery.b [...] gmail.com>
Subject: Re: [perl #131877] [LTA] better error message for exit("hello")
To: Carl Mäsak via RT <perl6-bugs-followup [...] perl.org>
Download (untitled) / with headers
text/plain 1.5k
At some point, one has to accept that this language is not Python, not call for one's favorite Python-isms to be incorporated into the core regardless of how it might interact with what is already there.

On Thu, Aug 10, 2017 at 8:12 AM, Aleks-Daniel Jakimenko-Aleksejev via RT <perl6-bugs-followup@perl.org> wrote:
Show quoted text
There's a little problem with it. You see, right now this works:

exit "1"

So we simply cannot force it to do something else with Strs because that can
break existing (perfectly valid) code. We can go through a long deprecation
cycle but it's not worth it (IMO).

But it may be possible to catch X::Str::Numeric exception and print better
message for this situation… ¯\_(ツ)_/¯

On 2017-08-10 02:09:30, szabgab@gmail.com wrote:
> In Python one can pass a string to the exit() function that will be
> displayed and the program exited.
>
>
> In Perl 6 I get:
>
> $ perl6
> To exit type 'exit' or '^D'
> > exit("hello")
> Cannot convert string to number: base-10 number must begin with valid
> digits or '.' in '⏏hello' (indicated by ⏏)
> in block <unit> at <unknown file> line 1
>
> Would it be possible to special case when someone passes a string to
> exit and give a better error message telling how to write that?
>
> Better yet, could exit accept a string?




--
brandon s allbery kf8nh                               sine nomine associates
allbery.b@gmail.com                                  ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 1.8k
On Thu, 10 Aug 2017 02:09:30 -0700, szabgab@gmail.com wrote: Show quoted text
> In Python one can pass a string to the exit() function > Would it be possible to special case
Not really keen on adding special cases to support programming-by-guessing instead of reading the documentation. However, it's worth noting we don't have anything on the same level of convenience as Perl's `die "foo\n"`; that is, printing some message to the user and aborting the program. `stuff() or (note "foo" and exit 1)` works, but is not a very obvious thing to use. Just thinking aloud: stuff() or exit :note<Some reasons>; stuff() or exit 42, :note<Some reasons>; stuff() or exit "Some reasons"; # ERROR: exit code status does not appear to be numeric; did you mean to use named `:note` argument to supply an exit message instead? P.S.: currently, there're more confusing errors existing in exit: m: my Str $code; exit $code rakudo-moar 5e8d46: OUTPUT: «Invocant of method 'Int' must be an object instance of type 'Str', not a type object of type 'Str'. Did you forget a '.new'?␤ in block <unit> at <tmp> line 1␤␤» However, the same exist in many other places: m: my Int $foo; say 42 < $foo rakudo-moar 5e8d46: OUTPUT: «Invocant of method 'Bridge' must be an object instance of type 'Int', not a type object of type 'Int'. Did you forget a '.new'?␤ in block <unit> at <tmp> line 1␤␤» So before adding any special cases anywhere, I think we should ask ourselves: what ingredients does a PDG (Pretty Damn Good) error message have that we can apply consistently on the language level? And then apply that consistently throughout all the errors. LTA errors is a pretty common topic, but we seem to be trying to solve the problem by shooting off the hip any time someone brings something up. How about a checklist for what an error must accomplish?
To: perl6-bugs-followup [...] perl.org
Subject: Re: [perl #131877] [LTA] better error message for exit("hello")
From: Gabor Szabo <szabgab [...] gmail.com>
Date: Thu, 10 Aug 2017 16:37:49 +0300
Download (untitled) / with headers
text/plain 1.2k
On Thu, Aug 10, 2017 at 3:59 PM, Zoffix Znet via RT <perl6-bugs-followup@perl.org> wrote: Show quoted text
> On Thu, 10 Aug 2017 02:09:30 -0700, szabgab@gmail.com wrote:
>> In Python one can pass a string to the exit() function >> Would it be possible to special case
> > Not really keen on adding special cases to support programming-by-guessing instead of reading the documentation.
I think these days it is way too much to expect people to read and remember(!) the documentation. At least no up-front. However a more common case is the frequent language switching. I keep typing Python constructs in Perl and Perl constructs in Python. Not to mention Perl 5 vs 6 constructs. And JavaScript too. Show quoted text
> LTA errors is a pretty common topic, but we seem to be trying to solve the problem by shooting off the hip any time someone brings something up. How about a checklist for what an error must accomplish?
I have not given much thought to it, but I'd like my language to treat me as a human. Instead of telling me I am stupid, it should give me direction to fix the problem. Pointing at the specific paragraph in the documentation can be part of it. Rakudo does this quite well in some cases. In others less so. The thing is that now that I try to recall when did Rakudo do well I cannot really remember. And that IMHO is a good thing.
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 2.1k
On Thu, 10 Aug 2017 06:37:58 -0700, szabgab@gmail.com wrote: Show quoted text
> However a more common case is the frequent language switching. I keep > typing Python constructs in Perl and Perl constructs in Python. Not to > mention Perl 5 vs 6 constructs. And JavaScript too.
This is really a double-edged sword. We have lots of detections for Perl-isms, for example. However, they drive me up the wall because, for me, 100% of the time they get triggered when I write perfectly valid Rakudo code and the compiler merely assumes (incorrectly) that I tried to write Perl code. Another thing is wall-of-text errors that I've seen people point to already. You can write a novel, explaining everything, but you can't make people read it. Show quoted text
> Instead of telling me I am stupid, it should give me > direction to fix the problem. Pointing at the specific paragraph in > the documentation can be part of it.
To play the devil's advocate, I want the error to be fewer than 5 words: a location and a hint. I'm competent at Rakudo, so I can easily figure out what part of code is wrong with only that information and the paragraph-length errors just get in my way, trying to parse the crux of the error. This difference of needs and opinions is why IMO core errors should just provide this… checklist… of elements important to an error and then custom exception handlers (something that we already support) can be used to cater actual errors to the proper demographic. Are you new to the language? Set RAKUDO_EXCEPTIONS_HANDLER env var in your system to `NewLearner` and get extensive errors explaining how and why. Do you want your errors to load relevant docs to display alongside the error? Set RAKUDO_EXCEPTIONS_HANDLER env var in your system to `DocsLoader`. Do you want your errors to just get straight to the point? Set RAKUDO_EXCEPTIONS_HANDLER env var in your system to `Terse`. You can't just claim that users who are new to the language and who don't want to read the docs are the demographic we're supposed to target with our errors, because then you leave out a huge swath of other programmers who don't want their terminals spammed with information they're not interested in.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org