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
Comments
From @szabgabIn Python one can pass a string to the exit() function that will be In Perl 6 I get: $ perl6
Would it be possible to special case when someone passes a string to Better yet, could exit accept a string? |
From @toolforger
Maybe the error message should indicate what types are allowed.
That would be equivalent to `print("hello");exit(0)`. TL;DR it shouldn't accept a string, that would be worse than throwing an |
The RT System itself - Status changed from 'new' to 'open' |
From @AlexDanielThere'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:
|
From @geekosaurAt some point, one has to accept that this language is not Python, not call On Thu, Aug 10, 2017 at 8:12 AM, Aleks-Daniel Jakimenko-Aleksejev via RT <
-- |
From @zoffixznetOn Thu, 10 Aug 2017 02:09:30 -0700, szabgab@gmail.com wrote:
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>; P.S.: currently, there're more confusing errors existing in exit: m: my Str $code; exit $code However, the same exist in many other places: m: my Int $foo; say 42 < $foo 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? |
From @szabgabOn Thu, Aug 10, 2017 at 3:59 PM, Zoffix Znet via RT
I think these days it is way too much to expect people to read and However a more common case is the frequent language switching. I keep
I have not given much thought to it, but I'd like my language to treat Rakudo does this quite well in some cases. In others less so. |
From @zoffixznetOn Thu, 10 Aug 2017 06:37:58 -0700, szabgab@gmail.com wrote:
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.
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. |
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. |
+1 |
Closing it then. Thanks! |
Migrated from rt.perl.org#131877 (status was 'open')
Searchable as RT131877$
The text was updated successfully, but these errors were encountered: