Vai al concatenamento del metodo e alla gestione degli errori

Question

Voglio creare un metodo che concatena l'API in Go. In tutti gli esempi riesco a trovare che le operazioni concatenate sembrano sempre avere successo, cosa che non posso garantire. Cerco quindi di estenderli per aggiungere il valore di ritorno dell'errore.

Se lo faccio come questo

package main 

import "fmt" 

type Chain struct { 
} 

func (v *Chain)funA() (*Chain, error) { 
    fmt.Println("A") 
    return v, nil 
} 
func (v *Chain)funB() (*Chain, error) { 
    fmt.Println("B") 
    return v, nil 
} 
func (v *Chain)funC() (*Chain, error) { 
    fmt.Println("C") 
    return v, nil 
} 

func main() { 
    fmt.Println("Hello, playground") 
    c := Chain{} 
    d, err := c.funA().funB().funC() // line 24 
} 

Il compilatore mi dice chain-err-test.go:24: multiple-value c.funA() in single-value context e non verrà compilato. Esiste un buon modo in modo che funcA, funcB e funcC possano segnalare un errore e interrompere quella catena?

Answer 1

C'è un buon modo così funcA, funcB e funcC può segnalare un errore e fermare quella catena?

Sfortunatamente no, non esiste una buona soluzione al problema. I workaround sono sufficientemente complessi (aggiungendo nei canali di errore, ecc.) Che il costo supera il guadagno.

Il concatenamento del metodo non è un idioma in Go (almeno non per metodi che possono possibilmente errori). Questo non perché ci sia qualcosa di particolarmente sbagliato nelle catene di metodi, ma una conseguenza dell'idioma di restituire errori invece di farsi prendere dal panico. Le altre risposte sono soluzioni alternative, ma nessuna è idiomatica.

Posso chiedere, non è idiomatico concatenare metodi in Go a causa della conseguenza di errore di ritorno come facciamo in Go, o è più in generale una conseguenza di avere più ritorni di metodo?

Buona domanda, ma non è perché Go supporta più resi. Python supporta più ritorni, e Java può anche tramite una classe Tuple<T1, T2>; le catene di metodi sono comuni in entrambe le lingue. Il motivo per cui queste lingue possono farla franca è perché comunicano in modo idiomatico gli errori tramite eccezioni. Le eccezioni interrompono immediatamente la catena di metodi e passano al relativo gestore di eccezioni. Questo è il comportamento che gli sviluppatori di Go stavano specificamente cercando di evitare scegliendo invece di restituire gli errori.

Answer 2

Se si ha il controllo sul codice e la firma funzione è identica si può scrivere qualcosa di simile:

func ChainCall(fns ...func() (*Chain, error)) (err error) { 
    for _, fn := range fns { 
     if _, err = fn(); err != nil { 
      break 
     } 
    } 
    return 
} 

playground

Answer 3

Che ne dite di questo approccio: creare una struttura che i delegati Chain e error e restituirlo al posto di due valori. es .:

package main 

import "fmt" 

type Chain struct { 
} 

type ChainAndError struct { 
    *Chain 
    error 
} 

func (v *Chain)funA() ChainAndError { 
    fmt.Println("A") 
    return ChainAndError{v, nil} 
} 

func (v *Chain)funB() ChainAndError { 
    fmt.Println("B") 
    return ChainAndError{v, nil} 
} 

func (v *Chain)funC() ChainAndError { 
    fmt.Println("C") 
    return ChainAndError{v, nil} 
} 

func main() { 
    fmt.Println("Hello, playground") 
    c := Chain{} 
    result := c.funA().funB().funC() // line 24 
    fmt.Println(result.error) 
}