Heh, this behavior lives its own life. See https://gist.github.com/Whateverable/df882a7545b2aa4cd0575909934f4c48
Since 2017.07 it is producing this message: Died with Exception Actually thrown at: in block <unit> at /tmp/m_9jvp4WTp line 1 I think that's reasonable. Marking as ｢testneeded｣. On 2015-05-01 07:34:20, jn...@jnthn.net wrote: > On Fri May 01 06:16:20 2015, masak wrote: > > <lucasb> m: Failure.new(Exception.new) > > <camelia> rakudo-moar a073f5: OUTPUT«No exception handler located for > > catch [...] > > <lucasb> m: Failure.new(Exception.new); 1 > > <camelia> rakudo-moar a073f5: OUTPUT«(signal SEGV)» > > <lucasb> I don't know why the last statement is special for rakudo... > > <moritz> it's not evaluated in sink context > > <lucasb> In "2;3;4", only 2 and 3 get warnings for useless use > > <moritz> which is kinda a bug > > <moritz> in the general case, when you have code inside a block, the > > last statement is returned > > <moritz> hence it's not in sink context > > <moritz> and we haven't fixed that for the mainline > > <jnthn> For the mainline, we didn't fix it 'cus the REPL wants it > > that > > way also... > > <moritz> right > > * jnthn will investigate the SEGV > > <moritz> m: Failure.new(Exception.new).sink > > <camelia> rakudo-moar a073f5: OUTPUT«(signal SEGV)» > > <moritz> there ya go > > <lucasb> moritz++ > > * masak submits rakudobug > > <moritz> Exception.new leaves $!ex and $!bt undefined > > <moritz> but the rest of the code assumes that they are set > > <moritz> and it's the catching/throwing code that generates a new > > exception and binds $!ex and $!bt into them > > <jnthn> moritz: Still shouldn't SEGV either way... > > It no longer SEGVs: > > C:\consulting\rakudo>perl6-m -e "Failure.new(Exception.new); 1" > Unhandled exception: concatenate requires a concrete string, but got > null > at <unknown>:1 > (././CORE.setting.moarvm:print_exception:4294967295) > from src/gen/m-CORE.setting:29455 > (././CORE.setting.moarvm:<anon>:40) > > But that probably isn't the right behavior either. So, the MoarVM bug > that caused the SEGV is gone, but we should figure out the Rakudo > behavior we want.
