user10089194's questions

Entendo o seguinte ponto em relação ao recover()comportamento em Go. recover()Segue avaliação imediata, mas execução atrasada .

Então, se ele não for chamado dentro de uma função adiada (trecho de código 1), ele recover()será avaliado naquele momento e, nesse ponto, ele ainda estará lá nile, portanto, nosso código entra em pânico.

Se for chamado dentro de uma função adiada, a chamada da função será registrada, mas recover() será chamada depois que ocorrer panice será recuperada com sucesso.

package main

import "fmt"

func main() {
    defer recover() // since not called inside a deferred func, it will not recover successfully

    panic("This is a panic")

}

Agora, tendo isso em mente, escrevi o código abaixo.

import (
    "fmt"
)

func main() {

    defer func(){
        customRecover()
    }()

    panic("This is a panic")

}

func customRecover(){
    if r:= recover(); r!= nil{
        fmt.Println("Custom Recovery for: ",r)
    }
}

Pesquisei online o raciocínio e obtive a mesma resposta que

O valor de retorno de recover é nulo se qualquer uma das seguintes condições for atendida:

• o argumento do pânico era nulo;
• a goroutine não está em pânico;
• recover não foi chamado diretamente por uma função adiada.

Mas não consigo entender por que o segundo snippet não está funcionando?!?

Ela satisfaz todas as 3 condições estritamente falando. Há alguma ressalva que eu esteja esquecendo? Acho que a 3ª condição não é satisfeita porque ela não é chamada diretamente, mas por meio de uma chamada de função aninhada. Mas por que ela precisa estar dentro de deferred somente?

Perguntas semelhantes: aqui , aqui , aqui e aqui .

Lendo simultaneidade em Go .

Tentando entender o padrão do canal or-done .

Estou com dificuldade para entender o fluxo de execução.

Mencionei o número na linha de onde vem minha dúvida.

1. Por que nenhuma returndeclaração em inner <-donecomo temos em outer select? Por causa de nenhuma returndeclaração, a próxima iteração será executada e se nessa iteração tivermos ambos <- donee <-cdisponíveis. Sabemos select-caseque escolheremos qualquer um dos casos arbitrariamente se vários casos estiverem disponíveis. Isso significa que há uma possibilidade de que <-cserá executado mesmo se <-doneestiver disponível?

2. Já que select-casearbitrariamente escolhe um caso quando vários casos estão disponíveis, é correto assumir que o <- doneserá escolhido eventualmente , mas não é necessário que seja escolhido imediatamente assim que for fechado. Claro, essa dúvida é quando ambos os casos, ie <-donee <-cestavam disponíveis.

3. Existe uma possibilidade que <- vnão está escrita valStreamquando doneé fechada e é perdida para sempre, correto?

orDone := func(done, c <-chan interface{}) <-chan interface{} {
    valStream := make(chan interface{})
    go func() {
        defer close(valStream)
        for {
            select {                   //2
            case <-done:
                return
            case v, ok := <-c:
                if ok == false {
                    return
                }
                select {
                case valStream <- v:   //3
                case <-done:           //1
                }
            }
        }
    }()
    return valStream
}

Basicamente, corrija-me se eu estiver errado ou confirme que meu entendimento da execução está correto. De fato, há "brechas" no código e isso é apenas comportamento do canal aqui.

Pergunta semelhante aqui