Distinguere tra eccezione e errore in un blocco CATCH [RAKU]

Sappiamo che un errore può essere gestito da un blocco CATCH.

Nel seguente esempio creiamo un errore "AdHoc" (in other-sub) e gestiamo l'eccezione in un blocco CATCH (in my-sub)

sub my-sub {
    try {
        CATCH {
            when X::AdHoc { say 'AdHoc Exception handled here'; .resume }
            default {say 'Other Exception'; .resume}
        }

        my $b = other-sub();

        $b.so ?? $b.say !! 'This was a Failure'.say;
    }
}

sub other-sub { fail 'Failure_X' }

my-sub();

L'output è il seguente:

AdHoc Exception handled here
This was a Failure

La mia domanda è però: come possiamo distinguere tra Failure e un'eccezione "normale" nel blocco CATCH per distinguere tra i due casi?

La relazione tra Failuree Exceptionè che a Failureha unException - vale a dire, contiene l'oggetto eccezione come parte del suo stato. Qualcosa come questo:

class Failure {
    has Exception $.exception;
    # ...
}

Quando un Failure"esplode", lo fa lanciando Exceptionciò che è al suo interno. Pertanto, ciò che raggiunge il CATCHblocco è l' Exceptionoggetto, e non vi è alcun collegamento con il recinto Failure. (In effetti, un datoException oggetto potrebbe in linea di principio essere trattenuto da molti Failures.)

Pertanto, non esiste un modo diretto per rilevare questo. Dal punto di vista del design, probabilmente non dovresti esserlo e dovresti trovare un modo diverso di risolvere il tuo problema. UNFailure è solo un modo per rinviare il lancio di un'eccezione e consentire che venga trattato come un valore; non si intende che la natura del problema sottostante cambi perché viene trasmessa come valore anziché come trasferimento immediato del flusso di controllo. Sfortunatamente, l'obiettivo iniziale non era indicato nella domanda; potresti trovare utile esaminare le eccezioni di controllo, ma in caso contrario potresti pubblicare un'altra domanda sul problema di fondo che stai cercando di risolvere. Probabilmente c'è un modo migliore.

Per completezza, noterò che ci sono modi indiretti in cui si può rilevare che il è Exceptionstato lanciato da a Failure. Ad esempio, se si ottiene l' .backtraceoggetto dell'eccezione e si osserva il pacchetto del frame superiore, è possibile determinare che proviene da Failure:

sub foo() { fail X::AdHoc.new(message => "foo") }
try {
    foo();
    CATCH {
        note do { no fatal; .backtrace[0].code.package ~~ Failure };
        .resume
    }
}

Tuttavia, questo dipende fortemente dai dettagli di implementazione che potrebbero facilmente cambiare, quindi non mi affiderei.

Basta rimuovere il trywrapper:

sub my-sub {

#    try {              <--- remove this line...

        CATCH {
            when X::AdHoc { say 'AdHoc Exception handled here'; .resume }
            default {say 'Other Exception'; .resume}
        }

        my $b = other-sub();

        $b.so ?? $b.say !! 'This was a Failure'.say;

#    }                  <--- ...and this one

}

sub other-sub { fail 'Failure_X' }

my-sub();

Hai usato try. A tryfa alcune cose, ma la cosa pertinente qui è che dice a Raku di promuovere immediatamente qualsiasi Failures nel suo ambito di eccezioni - che è ciò che dici di non voler. Quindi la soluzione più semplice è semplicemente smettere di farlo.

Questa risposta ripete solo verbalmente parte della spiegazione di jnthn (vedi in particolare i commenti che ha scritto sotto la sua risposta). Ma non ero convinto che tutti i lettori avrebbero individuato / compreso questo aspetto, e non pensavo che un commento o due sulla risposta di jnthn avrebbero aiutato, quindi questa risposta.

Ho scritto questo come una risposta della comunità per assicurarmi che non trarrò beneficio da alcun voto perché ovviamente non lo garantisce. Se ottiene abbastanza downvotes lo elimineremo semplicemente.