I have committed https://github.com/perl6/nqp/commit/59d7a8869c and this test
passes now.
As far as I understand, the right handler was missed when moving to the
outside, because unwind_check sets the outer handler to 0 by default if no
outer handler is passed. We do the latter now.
I'm
Oh, great! I was running the latest version I saw
listed in 'rakudobrew list-available' which is 2018.10:
~ $ perl6 -v
This is Rakudo version 2018.10 built on MoarVM version 2018.10
implementing Perl 6.c.
thanks!
Brian
On Saturday, November 10, Elizabeth Mattijsen wrote:
> In v6.d
In v6.d this throws the exception:
$ 6 'start die("bye"); sleep 1'
Unhandled exception in code scheduled on thread 4
bye
in code at -e line 1
whereas the exception is silently ignored in 6.c:
$ 6 'use v6.c; start die("bye"); sleep 1'
Not sure if this answers your question, as it is unclear
Hi Perl 6 Users,
What's the best way to know that an exception
occurred in another thread, e.g.
$ perl6 -e 'start say("hi"); sleep 1'
hi
$
but
$ perl6 -e 'start die("bye"); sleep 1'
$
I thought maybe $*SCHEDULER.uncaught_handler
would help out here, but it didn't seem to.
> >>> Not having written much exception-related code in Perl 6, I hoped that
> >>> this might work:
> >>>
> >>>sub divide($a, $b) { die "Zero denominator" if $b == 0; $a / $b }
> >>>my $quotient = do { divide($a, $b); CA
an tell, the value to which a CATCH
>>> block evaluates is ignored; the only useful things one can do in such a
>>> block are things with side effects. Long story short, I eventually came up
>>> with this:
>>>
>>>my $quotient = do { my $q; {
y $quotient = do { my $q; { $q = divide($a, $b); CATCH { default { $q
> > = -1 } } }; $q };
> >
> > That's far more verbose than I've come to expect from Perl 6. Is there
> > some more concise way of expressing this logic?
> >
> > The doc page on
one can do in such a
> block are things with side effects. Long story short, I eventually came up
> with this:
>
> my $quotient = do { my $q; { $q = divide($a, $b); CATCH { default { $q
> = -1 } } }; $q };
>
> That's far more verbose than I've come to expect from Perl 6. Is the
e doc page on exceptions mentions try, eg:
my $quotient = try { divide($a, $b) } // -1;
That works in this specific case, but it seems insufficient in general.
The function might validly return an undefined value, and this construction
can't distinguish between that and an exception. Also, i
On Thu, 08 Sep 2016 12:55:10 -0700, sml...@gmail.com wrote:
> If you `die` inside a `map/for` that is being `hyper/race`d...
>
> for (1..1).hyper { die }; sleep 1; say "Alive";
>
> ...it prints the exception's backtrace, but then resumes the program
> as if nothing had happened:
>
> Died
>
On Thu, 08 Sep 2016 12:55:10 -0700, sml...@gmail.com wrote:
> If you `die` inside a `map/for` that is being `hyper/race`d...
>
> for (1..1).hyper { die }; sleep 1; say "Alive";
>
> ...it prints the exception's backtrace, but then resumes the program
> as if nothing had happened:
>
> Died
>
# New Ticket Created by Zoffix Znet
# Please include the string: [perl #131504]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131504 >
I assumed the . form was just a nicer way of writing foo($_), however they
differ in
value. The actual explosion in OP's code happens when
one of the
Failures—created when 'flarg' was coerced to Numeric—is used as a value for
the purposes of evaluating the `==` op with it. That's when the Exception
gets thrown.
I'm unsure if one of the suggestions was to catch such exceptions and
value. The actual explosion in OP's code happens when
one of the
Failures—created when 'flarg' was coerced to Numeric—is used as a value for
the purposes of evaluating the `==` op with it. That's when the Exception
gets thrown.
I'm unsure if one of the suggestions was to catch such exceptions and
# New Ticket Created by Zoffix Znet
# Please include the string: [perl #131167]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131167 >
I had to fudge it for the release and will unfudge after the release.
The test tests if
On Wed, 02 Dec 2015 13:52:24 -0800, timo wrote:
> just about an exception in a
> Promise that nobody is interested in (no await, no .then, ...) are
> silently nommed:
This version has a `.then` but doesn't explode. Is it meant to then?
use v6;
my $foo;
my $promise = Promise.new;
On Mon Aug 10 14:20:34 2015, r...@hoelz.ro wrote:
> See the attached script.
>
> The original backtrace of an exception seems to vanish when awaiting a
> Promise throws that exception.
Now we show both backtraces, and more clearly explain what happened (that we're
throwing now because the
# New Ticket Created by Sam S.
# Please include the string: [perl #129234]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=129234 >
If you `die` inside a `map/for` that is being `hyper/race`d...
for (1..1).hyper { die };
# New Ticket Created by Zoffix Znet
# Please include the string: [perl #128470]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=128470 >
Hi,
I've tracked this issue to this commit:
For the records: There is a test for this ticket (currently fudged 'todo') in
S06-other/main-usage.t
s out internal
exceptions",
a summary of which appears below.
There is no need to reply to this message right now. Your ticket has been
assigned an ID of [perl #127977].
Please include the string:
[perl #127977]
in the subject line of all future correspondence about this issue. To
# New Ticket Created by Tadeusz Sośnierz
# Please include the string: [perl #127977]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=127977 >
$ cat test.pl
sub MAIN(@args where sub { False }) {
say ":)"
}
$ perl6 test.pl
On Wed Jul 15 21:09:12 2015, r...@hoelz.ro wrote:
> See the attached file.
>
> The code in the attached file should make some indication that
> something in the code called provided to Supply.tap is going wrong,
> but the execution completes silently.
The exceptions got lost
# New Ticket Created by Rob Hoelz
# Please include the string: [perl #125782]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/Ticket/Display.html?id=125782
See the attached script.
The original backtrace of an exception seems to vanish when
# New Ticket Created by Rob Hoelz
# Please include the string: [perl #125657]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/Ticket/Display.html?id=125657
For an example, see the attached script.
I understand that if the if $! { ... } block
# New Ticket Created by Rob Hoelz
# Please include the string: [perl #125621]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/Ticket/Display.html?id=125621
See the attached file.
The code in the attached file should make some indication that
:
M S32-setting-library/Exception.pod
Log Message:
---
Add StubCode to exceptions
On Mon May 11 05:26:45 2015, pmichaud wrote:
After discussion with jnthn at OSDC.no, here's what we propose:
In the regex engine, the default FAILGOAL behavior should be to simply
fail/backtrack. This would be the default behavior for (rakudo)
Cursor as well.
Grammars that wish to have
masak as an author of grammars, I still find it annoying and difficult that
grammars generally fail, that is, return a failing match -- *unless* you use
the `~` combinator, in which case they nqp::die with an exception that can't be
properly caught using a CATCH.
masak in effect, that gives
paths:
M S32-setting-library/Exception.pod
Log Message:
---
(S32/Exceptions) Add X::Range::InvalidArg exception.
:
M S32-setting-library/Str.pod
Log Message:
---
force exceptions to lc or uc
:
M S04-control.pod
Log Message:
---
A couple of fixes to the exceptions spec.
# New Ticket Created by Carl Mäsak
# Please include the string: [perl #106832]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=106832
moritz wow, it seems that nom's Failure doesn't expose the
underlying
Now fixed, and tested in t/spec/S04-exceptions/fail.t
On 12/22/2011 04:13 PM, Carl MXXsak (via RT) wrote:
# New Ticket Created by Carl Mäsak
# Please include the string: [perl #106832]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org:443/rt3
paths:
M S32-setting-library/Exception.pod
Log Message:
---
[S32::Exceptions] briefly describe the default exception printer
chdir still isn't throwing a CATCHable error. It now lives in
src/core/IO.pm
proto sub chdir(|$) { * }
multi sub chdir($path as Str) {
try {
pir::new__PS('OS').chdir($path)
}
$! ?? fail($!) !! True
}
--
Will Coke Coleda
On Wed Sep 16 02:56:54 2009, moritz wrote:
Thanks for the ticket, it's a very good catch and analysis.
I have some small comments on it:
Bruce Gray (via RT) wrote:
# New Ticket Created by Bruce Gray
# Please include the string: [perl #69160]
# in the subject line of all future
paths:
M S03-operators.pod
Log Message:
---
cmp does not throw exceptions, just fails
Also discuss mass production ops that tend to pass failures
through rather than throw them. Which ops are so considered
is of course a matter for ongoing negotiation.
Commit
paths:
M S29-functions.pod
Log Message:
---
eval() does not catch exceptions
S32-setting-library/Exception.pod
Log Message:
---
[S32/Exceptions] add a few syntax errors
S32-setting-library/Exception.pod
Log Message:
---
[S32/Exceptions] move %.payload into a separate class, based on feedback by
sorear++
On Tue Jun 08 12:33:03 2010, cognominal wrote:
I golfed the problematic statement to :
$ perl6
lc ~$_ for Match.^methods
lc ~$_ for Match.^methods
get_string() not implemented in class 'ArrayIterator'
$ say my mac is freaking me out # oops I was thrown out from the
rakudo shell
$
Author: lwall
Date: 2010-07-15 01:53:05 +0200 (Thu, 15 Jul 2010)
New Revision: 31691
Modified:
docs/Perl6/Spec/S04-control.pod
Log:
[S04] more bombastic utterances about not dropping pending exceptions
Modified: docs/Perl6/Spec/S04-control.pod
# New Ticket Created by Stephane Payrard
# Please include the string: [perl #75620]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=75620
I golfed the problematic statement to :
$ perl6
lc ~$_ for Match.^methods
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #75292]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=75292
Everything that produces an exception (doesn't matter if compile time or
run time)
# New Ticket Created by Mark Montague
# Please include the string: [perl #69991]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=69991
Exceptions from src/builtins/io.pir (and possibly elsewhere) are not
being
# New Ticket Created by Bruce Gray
# Please include the string: [perl #69160]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=69160
Consider these two classes, both faulty in the same way:
class B0rk { say $.a };
# New Ticket Created by Ben Petering
# Please include the string: [perl #68318]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=68318
# Normal exception in try {} is caught
BEGIN {
try {
widdle;
the contextual variable C$! contains all exceptions collected in
: the current lexical scope...
...that implies to my mind that $! is an exception object, but that an
exception object can contain more than one exception. Is that correct?
But the spec also says:
: Exceptions
On Thu, 26 Feb 2009, Timothy S. Nelson wrote:
My suggested solution would be to change $! to an exception container
object. But then we have to use it in the implicit given in the CATCH block.
If we used an any() Junction, would that do what we want?
Ok, Moritz told me on IRC that this
to have $! representing the last
exception, so you can still use
my $file = open 'file.txt' or die $!;
no matter how many unthrown exceptions you have in that block.
daniel
Em Qui, 2009-02-26 às 08:55 -0300, Daniel Ruoso escreveu:
for @! {}
might provide the needed semantics...
After sending this mail I've just realized I don't know exactly which
are the needed semantics...
what happens if you have several unthrown exceptions in the block, does
it throw every one
exceptions in the block, does
it throw every one of them? in sequence? autothreading? what happens if
one CATCH handles one of the exception but only an outer CATCH handles
the other?
I'm not sure there is a sane way of having several unthrown exceptions
at the same block, so I think the best thing we
S04 says:
Because the contextual variable C$! contains all exceptions collected in the
current lexical scope, saying Cdie $! will throw all exceptions,
whether they were handled or not. A bare Cdie/Cfail takes C$! as the
default argument.
Does this mean that $! is a container
On Thu, Feb 26, 2009 at 02:05:28PM +1100, Timothy S. Nelson wrote:
Does this mean that $! is a container of some sort?
It's an object, which (in the abstract) can contain anything it jolly
well pleases. The main question beyond that is how it responds if
used like one of the standard
On Thu Oct 23 07:13:46 2008, pmichaud wrote:
On Wed, Oct 22, 2008 at 08:27:10PM -0700, Tim Nelson via RT wrote:
On Sat Aug 16 07:29:31 2008, je...@perl.org wrote:
- Needs last/redo/next/continue exceptions in PCT (PCT)
This is done in rakudo; does that mean that this ticket is done
On Thu Oct 23 07:13:46 2008, pmichaud wrote:
On Wed, Oct 22, 2008 at 08:27:10PM -0700, Tim Nelson via RT wrote:
On Sat Aug 16 07:29:31 2008, je...@perl.org wrote:
- Needs last/redo/next/continue exceptions in PCT (PCT)
This is done in rakudo; does that mean that this ticket is done
# New Ticket Created by Christoph Otto
# Please include the string: [perl #60556]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60556
If an exception handler catches an exception from a MULTI function implemented
On Sat Aug 16 07:29:31 2008, [EMAIL PROTECTED] wrote:
- Needs last/redo/next/continue exceptions in PCT (PCT)
This is done in rakudo; does that mean that this ticket is done?
On Wed, Oct 22, 2008 at 08:27:10PM -0700, Tim Nelson via RT wrote:
On Sat Aug 16 07:29:31 2008, [EMAIL PROTECTED] wrote:
- Needs last/redo/next/continue exceptions in PCT (PCT)
This is done in rakudo; does that mean that this ticket is done?
Only 'next' is done in rakudo at the moment
On Tue Aug 05 04:09:14 2008, tene wrote:
pdd23:
Exception handlers can resume execution immediately after the
throw opcode by invoking the resume continuation which is stored
in the exception object. That continuation must be invoked with no
parameters; in other words, throw never returns
On Wednesday 20 August 2008 12:48:27 Reini Urban wrote:
make dotnet work with the new exceptions.
I'm not sure how to return the jump_point correctly, but it looks fine.
Thanks, applied as r30718.
-- c
On Wed Aug 27 22:49:37 2008, cotto wrote:
Most of these test wouldn't throw an exception anyway, since assigning
to a positive out-of-bounds element simply resizes the array. (This
excludes nonsensically large positive indicies, which should probably
tested for.) I added exception handling
On Thu Oct 25 00:49:38 2007, pcoch wrote:
To be totally honest I wish I knew. I'm just going through converting
the todo items in code into RT tickets and sometimes the todo comments
aren't necessarily all that clear as to what needs to be done. I'm
also (unfortunately) not familiar enough
Not long ago, Patrick R. Michaud proclaimed...
Here's a simple test for resumable exceptions that I'm trying
to get to work. I'm probably coding/understanding something wrong,
so any suggestions or pointers would be greatly appreciated.
.sub main :main
push_eh catcher
Here's a simple test for resumable exceptions that I'm trying
to get to work. I'm probably coding/understanding something wrong,
so any suggestions or pointers would be greatly appreciated.
.sub main :main
push_eh catcher
'foo'()
pop_eh
say 'ok 4
= gcc
---
Flags:
category=languages
severity=high
ack=no
---
make dotnet work with the new exceptions.
I'm not sure how to return the jump_point correctly, but it looks fine.
---
Summary of my parrot 0.7.0 (r0) configuration:
configdate='Wed Aug 20 18:34:46 2008 GMT
Patrick R. Michaud wrote:
What I'm trying to do is to test the ability to resume after
exceptions thrown by Cfoo. The Cmain sub above sets up
a handler to catch exceptions, then calls Cfoo. The handler
simply resumes any exception that is caught. The Cfoo sub
prints 'ok 1', throws
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #57978]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57978
- Needs last/redo/next/continue exceptions in PCT (PCT)
Thank you very much!
my $bill =
try ack() orelse
try thpp() orelse
do ppt();
This certainly does what I asked for, and it's short enough (even if we
need to add a few brackets).
Yes, the basic problem with the proposal is that it catches all
exceptions willy nilly
HaloO,
Yaakov Belch wrote:
I believe that ---from a usability point of view--- it's very important to:
* classify exceptions by severity or other characteristics,
* provide named adverbs/pragmas to modify default CATCH handlers,
* make them configurable by outer scopes.
[..]
The programmer
In a little language that I wrote some time ago, I found it very useful to
let the // operator catch exceptions:
f(x) // g(y) does:
* If f(x) returns a defined value, use this value.
* If f(x) returns an undefined value, use the value of g(x) instead.
* If f(x) throws an exception, catch and keep
On Wed, Aug 6, 2008 at 8:58 AM, Yaakov Belch [EMAIL PROTECTED] wrote:
In a little language that I wrote some time ago, I found it very useful to
let the // operator catch exceptions:
f(x) // g(y) does:
* If f(x) returns a defined value, use this value.
* If f(x) returns an undefined value
in my mind, this strays too far from the meaning of C// and adds
ambiguity that makes the operator unusable. perhaps there's room for
an operator that gives some sugar for
my $bill = try { ack() CATCH { thpp() } };
but to me that code is concise enough that it doesn't warrant syntactic
On Wed, Aug 06, 2008 at 09:36:16AM -0700, jerry gay wrote:
: i don't think this will work for perl 6. since perl 6 has resumeable
: exceptions (like Cwarn), the meaning of the C// operator could be
: ambiguous. given the following statement,
:
: my $bill = ack() // thpp() // ppt
;
compute_statistics($data) // write_log_message(stats failed: $!);
With the proposed change, these ideoms work whether the functions throw
exceptions or not.
You can change the meaning of fail to throw exceptions or to return
the unthrown object which is an interesting value of undef. So under
use fail
+608,29 @@ Exception message: Class Foo already registered!
after compile
OUTPUT
+pir_output_is( 'CODE', 'OUTPUT', Resumable exceptions );
+.sub main :main
+push_eh _handler
+new $P1, 'Exception'
+say 'Before throwing'
+throw $P1
+say 'After throwing'
+end
+_handler
# New Ticket Created by Vasily Chekalkin
# Please include the string: [perl #56216]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56216
Hello.
Attached patch handles parrot's exception on substr invocations and
handler in its list? If so, how do we model this control flow?
More on control flow tomorrow.
I started to write this out, and then realized I already did in the
Exceptions PDD.
Allison
the scheduler that it has handled (or will handle) the exception by
using the handled opcode. PDD 25 suggests that there are Task PMCs which
represent or encapsulate these exceptions.
Presumably the handled opcode will remove the exception Task from the
scheduler and resume execution at the appropriate
handled (or will handle) the exception by
using the handled opcode. PDD 25 suggests that there are Task PMCs which
represent or encapsulate these exceptions.
Presumably the handled opcode will remove the exception Task from the
scheduler and resume execution at the appropriate point. Presumably
pdb. Fixing pdb to catch exceptions cleanly would
make pdb significantly more useful as a debugger, I think.
Mark
Friends,
Doing cage cleaning today, I noticed that there has been no activity in
this thread since last August. Are the issues that were under
discussion still live? Should we still be considering the various
patches?
Update sought. Thank you very much.
kid51
and *any* ResizeablesomethingArray needs the
exceptions-related tests updated when we have exceptions implemented.
Could you explain more fully what the problem is? Since we're currently
implementing the exceptions PDD, it would be helpful to know any edge
cases that need to be fixed
Kevin Tew wrote:
exceptions_ops.diff adds some simple ops needed for PDD compliance.
exceptions.diff attempts to change all instances of clear_eh to pop_eh.
Looks good.
The exception handler stack introspection interface you added to the PDD
is solid. The stack will be replaced by the
On 10/24/07, Allison Randal [EMAIL PROTECTED] wrote:
Kevin Tew wrote:
exceptions_ops.diff adds some simple ops needed for PDD compliance.
exceptions.diff attempts to change all instances of clear_eh to pop_eh.
Looks good.
The exception handler stack introspection interface you added to
jerry gay wrote:
i'd prefer 'count_eh', to match every other exception handler related
op that has an '_eh' suffix. seems silly to have just one with a 'eh_'
prefix.
'count_eh' isn't distinctive enough.
Another possibility is not to provide an opcode for the number of
exception handlers,
these properly when we have exceptions
Which is to say that the tests of various error conditions and their output
needs to be tested more thoroughly when exceptions are implemented.
/resizeablepmcarray.t there is the todo item:
# TODO: Rewrite these properly when we have exceptions
Which is to say that the tests of various error conditions and their output
needs to be tested more thoroughly when exceptions are implemented.
I updated the subject of this ticket to substitute PMC
Paul Cochrane wrote:
I updated the subject of this ticket to substitute PMC with * as this
issue occurs more often than I first guessed (the problems one has
when going through code serially...). This issue is actually more
general and *any* ResizeablesomethingArray needs the
exceptions
; /* TODO 1 - Exceptions !!! */
I think this means to handle exceptions wrt reference counts correctly, but
I'm really not sure.
This patch makes parrot stop execution of the vm when running as a
debugger.
This makes the pdb stop executing and shows the exception message
instead of silently exiting.
Hi, pancake!
I have tried to update your patch to svn r20469, see attached patch.
Unfortunately, it doesn't work any
# New Ticket Created by Jerry Gay
# Please include the string: [perl #44139]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44139
the api for opcodes needs review, especially with regard to the
response to
to make their resumable-exception handlers short, or to only
throw non-resumable exceptions from blocks that are likely to be called
in such circumstances. I suppose that would be an acceptable resolution,
but it has an aura of non--re-entrant signal handlers about it, so it
seems like the sort
the lock at some later
: date, seems to be far from the best choice. Sure, we can warn
: programmers to make their resumable-exception handlers short, or to only
: throw non-resumable exceptions from blocks that are likely to be called
: in such circumstances. I suppose that would be an acceptable
is not unwound until some exception handler chooses to
unwind it by handling the exception in question.
Yes, I did. I was grepping specifically for the bit on resumable
exceptions and the quoted bit is 80 lines up so I missed it completely.
Thanks for pointing me at it.
[...]
To resume
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #40824]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40824
If a loadlib fails, it doesn't throw a catchable exception. The t/
library/pg.t
From: Matt Diephouse (via RT) [EMAIL PROTECTED]
Date: Sat, 11 Nov 2006 16:46:20 -0800
If a loadlib fails, it doesn't throw a catchable exception. The t/
library/pg.t test was changed because it was failing on platforms
where pg wasn't available. In particular, this assertion was
chromatic has already committed this as
r15413.
It just gets the test to pass; there are still outstanding questions with
regard to exceptions and continuations and the C barrier.
-- c
catch exceptions in the code and return the error message
This ticket is in response to cage task #39704.
1 - 100 of 306 matches
Mail list logo
