Possible Bug with run as Last Statement in try Block

Question

I don't know if this is a bug, or I just don't understand what's happening. If I have a run statement as the last statement in a try block, any error in the run statement is not caught. If it is not the last statement in the block, the exception is caught. Here's what I get when run is the last statement:

try {
  CATCH {
    default {
      say 'CAUGHT!';
    }
  }

  run 'lss', '-al';
}

Output:

$ raku try-run-bug.raku 
The spawned command 'lss' exited unsuccessfully (exit code: -1, signal: 254)
(OS error = Failed to spawn process lss: no such file or directory (error code -2))
  in block <unit> at try-run-bug.raku line 1

Here's what I get if it isn't the last statement:

try {
  CATCH {
    default {
      say 'CAUGHT!';
    }
  }

  run 'lss', '-al';
  say 'foo';
}

Output:

$ raku try-run-bug-workaround.raku
CAUGHT!

This has been tested on:

$ raku -v
Welcome to Rakudo™ v2024.09.
Implementing the Raku® Programming Language v6.d.
Built on MoarVM version 2024.09.

via rakubrew.

Edit

Based on a comment below, I did try moving the CATCH block to the bottom in the first example, and it did fix the problem. It still seems like a bug to me because I thought that CATCH blocks could appear anywhere within the scope of the line that throws the exception. Please correct me if I'm wrong.

Noble

I don't know raku, but in every other language I've seen, you try something first, and catch any issue afterward, as in try this catch error. I'm not sure why you would catch before you even try. try catch error do this doesn't seem to make any sense. How can there be a problem to catch before you've done anything at all? – Moorish

@KenWhite, in Raku, exceptions get caught by the CATCH in the same scope as the line that throws the exception. It's a little different than other languages. The docs actually show putting the CATCH block at the top (docs.raku.org/syntax/try%20blocks), but it shouldn't matter as long as it's in the same scope. That being said, I did try it with the CATCH at the bottom, and it does correctly catch it. I'll update the question with that info. – Noble

run seems to have a CATCH block itself, so you don't get to catch yourself the X::OS error. As to why moving it around catches something: if it is in a sink context (it is in the 2nd one but not 1st), it throws X::Proc::Unsuccessful, and that's what you catch (still not the X::OS). This is my understanding but I'm not sure if this is a bug or working as desired, hence not making an answer. – Nitza

I think the bugful part might be why the first one is not deduced as a sink context, too. – Nitza

@MustafaAydın, Thanks for that info. I guess I'll see if someone else weighs in with whether this is expected or not, and on the sink context issue. At the very least, it should be documented, because I found it quite surprising. – Noble

see https://mcmap.net/q/1004228/-catching-exception-of-a-shell-command-in-perl-6 – Unexceptionable

@Unexceptionable is right, it is a when-do-I-sink problem... – Guenna

another thing: Jupyter::Chatbook is your friend, I executed your sample code in a cell, and that made me see the difference between the versions of it. – Guenna