Re: exceptions in threads
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 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 from your question > on which version you are running. > > > > > On 10 Nov 2018, at 13:59, Brian Duggan wrote: > > > > 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. > > > > thanks > > Brian
Re: exceptions in threads
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 from your question on which version you are running. > On 10 Nov 2018, at 13:59, Brian Duggan wrote: > > 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. > > thanks > Brian
exceptions in threads
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. thanks Brian