Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

better error message for exit("hello") #6438

Closed
p6rt opened this issue Aug 10, 2017 · 11 comments
Closed

better error message for exit("hello") #6438

p6rt opened this issue Aug 10, 2017 · 11 comments
Labels
LTA Less Than Awesome; typically an error message that could be better

Comments

@p6rt
Copy link

p6rt commented Aug 10, 2017

Migrated from rt.perl.org#131877 (status was 'open')

Searchable as RT131877$

@p6rt
Copy link
Author

p6rt commented Aug 10, 2017

From @szabgab

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?

@p6rt
Copy link
Author

p6rt commented Aug 10, 2017

From @toolforger

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.

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

@p6rt
Copy link
Author

p6rt commented Aug 10, 2017

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Aug 10, 2017

From @AlexDaniel

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?

@p6rt
Copy link
Author

p6rt commented Aug 10, 2017

From @geekosaur

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​:

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

@p6rt
Copy link
Author

p6rt commented Aug 10, 2017

From @zoffixznet

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.

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?

@p6rt
Copy link
Author

p6rt commented Aug 10, 2017

From @szabgab

On Thu, Aug 10, 2017 at 3​:59 PM, Zoffix Znet via RT
<perl6-bugs-followup@​perl.org> wrote​:

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.

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.

@p6rt
Copy link
Author

p6rt commented Aug 10, 2017

From @zoffixznet

On Thu, 10 Aug 2017 06​:37​:58 -0700, szabgab@​gmail.com wrote​:

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.

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.

@p6rt p6rt added the LTA Less Than Awesome; typically an error message that could be better label Jan 5, 2020
@JJ
Copy link

JJ commented Dec 31, 2020

I think this could be closed. The error issued is consistent with the behavior. If no one is against, I'll close it in a few days/hours.

@toolforger
Copy link

+1

@JJ
Copy link

JJ commented Jan 1, 2021

Closing it then. Thanks!

@JJ JJ closed this as completed Jan 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LTA Less Than Awesome; typically an error message that could be better
Projects
None yet
Development

No branches or pull requests

3 participants