[perl #125621] Uncaught exceptions in Supply.tap are silenced
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 due to a thinko in the scheduler. Fixed now, and test added to S17-supply/interval.t. /jnthn
Re: confused about 'try'
Hi,
On 11/24/2015 06:39 AM, brad clawsie wrote:
> Been playing with perl6 and it is truly amazing.
>
> I'm somewhat confused as to when I should should wrap subroutine
> invocations with `try`. My `CATCH` clauses seem to be able to catch
> thrown Exception instances if I use `try` or not.
That's correct. "try" is merely a convience for catching all exceptions,
and not needed when you have an explicit CATCH block.
> I see in the
> "Exceptional Perl 6" slide deck
> ( http://moritz.faui2k3.org/files/talks/2013-yapc-p6-exceptions/ ),
> there seems to be an indication that `try` should be used when I want to
> access a Backtrace...is there something here I am missing?
The exception object always gives you access to the backtrace. If you
use CATCH, then the exception is in $_ inside the CATCh block. If you
use try, the exception is in $! outside the try block.
Here are two examples that do the same thing:
try { die "oh noez" };
say $!.message; # oh noez
say $!.^name; # X::AdHoc
do {
die "oh noez";
CATCH {
default {
say .message; # oh noez
say .^name; # X::AdHoc
}
}
}
Why bother with the more verbose form at all? There are basically two
reasons:
1) you can chose to only catch some exceptions, like
EVAL $some-code;
CATCH {
when X::Comp { say "Your code didn't even compile" };
# let run-time exceptions fall through
}
2) When you want to access some variables from the inner scope that
produced the exception. Since CATCH runs before the stack is unwound,
you can even inspect dynamic variables.
Cheers,
Moritz
[perl #126725] List.print and print(List) differ
# New Ticket Created by Wenzel Peppmeyer
# Please include the string: [perl #126725]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126725 >
my $list = (1,2,3);
print $list;
put;
$list.print;
# OUTPUT«1 2 3123»
# The output of both forms should be the same. List should .Str to
.join(' '). Array is List, so $list.print should have the appropriate
amount of WS.
[perl #126724] [BUG] Unsatisfactory internal error when trying to compose two roles (connected with 'does') that share the same private attribute in Rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #126724]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126724 >
m: role R { has $.x }; role S does R { has $.x }; S.new
rakudo-moar : OUTPUT«Cannot find method 'collisions' [...]
I'm confused by this error message.
I can understand if there's some kind of collision between R
and S (because of $.x), but the error message isn't really explaining
itself well.
should the above be legal, rather than an error?
It looks like an error while producing an error...
yeah...
m: role R { has $.x }; class S does R { has $.x }; S.new
rakudo-moar : OUTPUT«===SORRY!===Attribute '$!x' already
exists in the class 'S', but a role also wishes to compose it»
looks like in the auto-punning of the role ?
Maybe
I can't look now, I'm trying to untangle supplies...
jnthn: should I rakudobug it?
masak: Pretty sure the collisoins not found while trying to do
error reporting is in there, but can be good to check
masak: the error seems familiar, wouldn't be surprised if
there is a ticket for it already
* masak submits rakudobug
m: role R { has $!x }; role S does R { has $!x }; S.new
rakudo-moar : OUTPUT«Cannot find method 'collisions' [...]
