Concordo que este é o melhor caminho a seguir: corrigir o problema mais comum com um design simples.

Eu não quero andar de bicicleta (sinta-se à vontade para adiar esta conversa), mas Rust foi até lá e acabou acertando com o operador ? postfix em vez de uma função interna, para maior legibilidade.

A proposta do gophercon cita ? nas ideias consideradas e dá três razões pelas quais foi descartada: a primeira ("transferências de fluxo de controle são geralmente acompanhadas de palavras-chave") e a terceira ("manipuladores são definidos mais naturalmente com uma palavra-chave, portanto, as verificações também devem") não se aplicam mais. A segunda é estilística: diz que, mesmo que o operador postfix funcione melhor para encadeamento, ele ainda pode ler pior em alguns casos como:

check io.Copy(w, check newReader(foo))

em vez de:

io.Copy(w, newReader(foo)?)?

mas agora teríamos:

try(io.Copy(w, try(newReader(foo))))

o que eu acho que é claramente o pior dos três, já que nem é mais óbvio qual é a função principal que está sendo chamada.

Portanto, a essência do meu comentário é que todas as três razões citadas na proposta do gophercon para não usar ? não se aplicam a esta proposta try ; ? é conciso, muito legível, não obscurece a estrutura da instrução (com sua hierarquia interna de chamada de função) e é encadeável. Ele remove ainda mais a desordem da exibição, sem obscurecer o fluxo de controle mais do que o try() proposto já faz.

Esclarecer:

Faz

func f() (n int, err error) {
  n = 7
  try(errors.New("x"))
  // ...
}

return (0, "x") ou (7, "x")? Eu assumiria o último.

O retorno de erro deve ser nomeado no caso em que não há decoração ou manipulação (como em uma função auxiliar interna)? Eu suponho que não.

Seu exemplo retorna 7, errors.New("x") . Isso deve ficar claro no documento completo que será enviado em breve (https://golang.org/cl/180557).

O parâmetro de resultado de erro não precisa ser nomeado para usar try . Ele só precisa ser nomeado se a função precisar se referir a ele em uma função diferida ou em outro lugar.

Estou realmente insatisfeito com um _function_ embutido que afeta o fluxo de controle do chamador. Eu aprecio a impossibilidade de adicionar novas palavras-chave no Go 1, mas resolver esse problema com funções incorporadas mágicas parece errado para mim. O sombreamento de outros internos não tem resultados tão imprevisíveis quanto a alteração do fluxo de controle.

Não gosto da aparência do postfix ? , mas acho que ainda supera try() .

Edit: Bem, eu consegui esquecer completamente que o pânico existe e não é uma palavra-chave.

A proposta detalhada já está aqui (pendente de melhorias de formatação, em breve) e esperamos responder a muitas perguntas.

@dominikh A proposta detalhada discute isso detalhadamente, mas observe que panic e recover são dois componentes internos que também afetam o fluxo de controle.

Um esclarecimento/sugestão de melhoria:

if the last argument supplied to try, of type error, is not nil, the enclosing function’s error result variable (...) is set to that non-nil error value before the enclosing function returns

Isso poderia dizer is set to that non-nil error value and the enclosing function returns ? (s/antes/e)

Na primeira leitura, before the enclosing function returns parecia que _eventualmente_ definiria o valor do erro em algum ponto no futuro logo antes da função retornar - possivelmente em uma linha posterior. A interpretação correta é que try pode fazer com que a função atual retorne. Esse é um comportamento surpreendente para o idioma atual, portanto, um texto mais claro seria bem-vindo.

Eu acho que isso é apenas açúcar, e um pequeno número de oponentes vocais provocou golang sobre o uso repetido de digitar if err != nil ... e alguém levou isso a sério. Eu não acho que seja um problema. As únicas coisas que faltam são esses dois built-ins:

https://github.com/purpleidea/mgmt/blob/a235b760dc3047a0d66bb0b9d63c25bc746ed274/util/errwrap/errwrap.go#L26

Não tenho certeza por que alguém escreveria uma função como essa, mas qual seria a saída prevista para

try(foobar())

Se foobar retornou (error, error)

Retiro minhas preocupações anteriores sobre o fluxo de controle e não sugiro mais usar ? . Peço desculpas pela resposta automática (embora eu gostaria de salientar que isso não teria acontecido se o problema tivesse sido arquivado _depois_ que a proposta completa estivesse disponível).

Discordo da necessidade de tratamento simplificado de erros, mas tenho certeza de que é uma batalha perdida. try conforme estabelecido na proposta parece ser a maneira menos ruim de fazer isso.

@webermaster Apenas o último resultado error é especial para a expressão passada para try , conforme descrito no documento da proposta.

Como @dominikh , também discordo da necessidade de tratamento de erros simplificado.

Ele move a complexidade vertical para a complexidade horizontal, o que raramente é uma boa ideia.

Se eu realmente tivesse que escolher entre simplificar as propostas de tratamento de erros, essa seria minha proposta preferida.

Seria útil se isso pudesse ser acompanhado (em algum estágio de aceitação) por uma ferramenta para transformar o código Go para usar try em algum subconjunto de funções de retorno de erro onde tal transformação pode ser facilmente executada sem mudando a semântica. Três benefícios me ocorrem:

• Ao avaliar esta proposta, permitiria que as pessoas tivessem uma noção rápida de como try poderia ser usado em sua base de código.
• Se try chegar a uma versão futura do Go, as pessoas provavelmente desejarão alterar seu código para usá-lo. Ter uma ferramenta para automatizar os casos fáceis vai ajudar muito.
• Ter uma maneira de transformar rapidamente uma grande base de código para usar try facilitará a análise dos efeitos da implementação em escala. (Correção, desempenho e tamanho do código, digamos.) A implementação pode ser simples o suficiente para tornar isso uma consideração insignificante, no entanto.

Eu só gostaria de expressar que acho que um simples try(foo()) realmente saindo da função de chamada tira de nós a sugestão visual de que o fluxo da função pode mudar dependendo do resultado.

Eu sinto que posso trabalhar com try com o suficiente para nos acostumarmos, mas também sinto que precisaremos de suporte IDE extra (ou algo assim) para destacar try para reconhecer eficientemente o fluxo implícito nas revisões de código /sessões de depuração

A coisa que mais me preocupa é a necessidade de ter valores de retorno nomeados apenas para que a instrução defer seja feliz.

Eu acho que o problema geral de tratamento de erros que a comunidade reclama é uma combinação do clichê de if err != nil E adicionar contexto aos erros. O FAQ afirma claramente que o último é deixado de fora intencionalmente como um problema separado, mas sinto que isso se torna uma solução incompleta, mas estarei disposto a dar uma chance depois de pensar nessas duas coisas:

1. Declare err no início da função.
   Isto funciona? Lembro-me de problemas com adiar e resultados sem nome. Se não, a proposta precisa considerar isso.

func sample() (string, error) {
  var err error
  defer fmt.HandleErrorf(&err, "whatever")
  s := try(f())
  return s, nil
}

1. Atribua valores como fizemos no passado, mas use uma função auxiliar wrapf que tenha o clichê if err != nil .

func sample() (string, error) {
  s, err := f()
  try(wrapf(err, "whatever"))
  return s, nil
}
func wrapf(err error, format string, ...v interface{}) error {
  if err != nil {
    // err = wrapped error
  }
  return err
}

Se qualquer um funcionar, eu posso lidar com isso.

func sample() (string, error) {
  var err error
  defer fmt.HandleErrorf(&err, "whatever")
  s := try(f())
  return s, nil
}

Isso não funcionará. O adiamento atualizará a variável local err , que não está relacionada ao valor de retorno.

func sample() (string, error) {
  s, err := f()
  try(wrapf(err, "whatever"))
  return s, nil
}
func wrapf(err error, format string, ...v interface{}) error {
  if err != nil {
    // err = wrapped error
  }
  return err
}

Isso deve funcionar. No entanto, ele chamará wrapf mesmo em um erro nulo.
Isso também (continuará a) funcionar, e a IMO é muito mais clara:

func sample() (string, error) {
  s, err := f()
  if err != nil {
      return "", wrap(err)
  }
  return s, nil
}

Ninguém vai fazer você usar try .

Não tenho certeza por que alguém escreveria uma função como essa, mas qual seria a saída prevista para

try(foobar())

Se foobar retornou (error, error)

Por que você retornaria mais de um erro de uma função? Se você estiver retornando mais de um erro da função, talvez a função deva ser dividida em duas separadas em primeiro lugar, cada uma retornando apenas um erro.

Poderia detalhar com um exemplo?

@cespare : Deve ser possível para alguém escrever um go fix que reescreva o código existente adequado para try modo que use try . Pode ser útil ter uma ideia de como o código existente pode ser simplificado. Não esperamos nenhuma mudança significativa no tamanho ou desempenho do código, já que try é apenas açúcar sintático, substituindo um padrão comum por um código-fonte mais curto que produz essencialmente o mesmo código de saída. Observe também que o código que usa try será obrigado a usar uma versão Go que seja pelo menos a versão na qual try foi introduzido.

@lestrat : Concordou que terá que aprender que try pode alterar o fluxo de controle. Suspeitamos que os IDEs poderiam destacar isso com bastante facilidade.

@Goodwine : Como @randall77 já apontou, sua primeira sugestão não funcionará. Uma opção que pensamos (mas não discutida no documento) é a possibilidade de ter alguma variável pré-declarada que denota o resultado error (se estiver presente em primeiro lugar). Isso eliminaria a necessidade de nomear esse resultado apenas para que ele possa ser usado em um defer . Mas isso seria ainda mais mágico; não parece justificado. O problema em nomear o resultado de retorno é essencialmente cosmético, e onde isso mais importa é nas APIs geradas automaticamente servidas por go doc e amigos. Seria fácil resolver isso nessas ferramentas (veja também o FAQ do documento de design detalhado sobre este assunto).

@nictuku : Em relação à sua sugestão de esclarecimento (s/antes/e/): acho que o código imediatamente antes do parágrafo ao qual você está se referindo deixa claro o que acontece exatamente, mas vejo seu ponto, s/antes/e/pode tornar a prosa mais clara. Eu vou fazer a mudança.

Veja CL 180637 .

Na verdade, gosto muito desta proposta. No entanto, tenho uma crítica. O ponto de saída das funções em Go sempre foi marcado por um return . Pânicos também são pontos de saída, no entanto, esses são erros catastróficos que normalmente não devem ser encontrados.

Fazer um ponto de saída de uma função que não é return , e deve ser comum, pode levar a um código muito menos legível. Eu tinha ouvido falar sobre isso em uma palestra e é difícil não ver a beleza de como esse código está estruturado:

func CopyFile(src, dst string) error {
    r, err := os.Open(src)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    defer r.Close()

    w, err := os.Create(dst)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if _, err := io.Copy(w, r); err != nil {
        w.Close()
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if err := w.Close(); err != nil {
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
}

Este código pode parecer uma grande bagunça e foi _significado_ pelo rascunho de tratamento de erros, mas vamos compará-lo com a mesma coisa com try .

func CopyFile(src, dst string) error {
    defer func() {
        err = fmt.Errorf("copy %s %s: %v", src, dst, err)
    }()
    r, err := try(os.Open(src))
    defer r.Close()

    w, err := try(os.Create(dst))

    defer w.Close()
    defer os.Remove(dst)
    try(io.Copy(w, r))
    try(w.Close())

    return nil
}

Você pode olhar para isso à primeira vista e achar que parece melhor, porque há muito menos código repetido. No entanto, foi muito fácil identificar todos os pontos que a função retornou no primeiro exemplo. Eles foram todos recuados e começaram com return , seguido por um espaço. Isso se deve ao fato de que todos os retornos condicionais _devem_ estar dentro de blocos condicionais, sendo assim indentados pelos padrões gofmt . return também é, como dito anteriormente, a única maneira de sair de uma função sem dizer que ocorreu um erro catastrófico. No segundo exemplo, há apenas um único return , então parece que a única coisa que a função _ever_ deve retornar é nil . As duas últimas chamadas try são fáceis de ver, mas as duas primeiras são um pouco mais difíceis, e seriam ainda mais difíceis se estivessem aninhadas em algum lugar, ou seja, algo como proc := try(os.FindProcess(try(strconv.Atoi(os.Args[1])))) .

Retornar de uma função parece ter sido uma coisa "sagra" a se fazer, e é por isso que eu pessoalmente acho que todos os pontos de saída de uma função devem ser marcados por return .

Alguém já implementou isso há 5 anos. Se você estiver interessado, você pode
experimente este recurso

https://news.ycombinator.com/item?id=20101417

Implementei try() no Go há cinco anos com um pré-processador AST e usei em projetos reais, ficou bem legal: https://github.com/lunixbochs/og

Aqui estão alguns exemplos de mim usando-o em funções pesadas de verificação de erros: https://github.com/lunixbochs/poxd/blob/master/tls.go#L13

Eu aprecio o esforço que foi feito para isso. Eu acho que é a solução mais go-ey que eu vi até agora. Mas eu acho que introduz um monte de trabalho ao depurar. Desembrulhar tente e adicionar um bloco if toda vez que depurar e reembalá-lo quando terminar é tedioso. E também tenho um certo receio sobre a variável mágica de erro que preciso considerar. Eu nunca me incomodei com a verificação explícita de erros, então talvez eu seja a pessoa errada para perguntar. Sempre me pareceu "pronto para depurar".

@griesemer
Meu problema com sua proposta de uso de defer como forma de lidar com o empacotamento de erros é que o comportamento do snippet que mostrei (repetido abaixo) não é muito comum AFAICT, e por ser muito raro, posso imaginar pessoas escrevendo isso pensando que funciona quando não.

Tipo.. um iniciante não saberia disso, se eles tiverem um bug por causa disso eles não vão "claro, eu preciso de um retorno nomeado", eles ficariam estressados ​​porque deveria funcionar e não funciona.

var err error
defer fmt.HandleErrorf(err);

try já é muito mágico, então você pode ir até o fim e adicionar esse valor de erro implícito. Pense nos iniciantes, não naqueles que conhecem todas as nuances do Go. Se não estiver claro o suficiente, não acho que seja a solução certa.

Ou... Não sugira usar adiar assim, tente outra maneira que seja mais segura, mas ainda legível.

@deanveloper É verdade que esta proposta (e, nesse caso, qualquer proposta que tente a mesma coisa) removerá instruções return explicitamente visíveis do código-fonte - esse é o objetivo da proposta, afinal, não é? Para remover o clichê das instruções if e returns que são todas iguais. Se você quiser manter os return , não use try .

Estamos acostumados a reconhecer imediatamente instruções return (e panic 's) porque é assim que esse tipo de fluxo de controle é expresso em Go (e muitas outras linguagens). Não parece muito improvável que também reconheçamos try como fluxo de controle de mudança depois de nos acostumarmos com isso, assim como fazemos para return . Não tenho dúvidas de que um bom suporte IDE também ajudará nisso.

Tenho duas preocupações:

• retornos nomeados têm sido muito confusos, e isso os encoraja com um novo e importante caso de uso
• isso irá desencorajar a adição de contexto aos erros

Na minha experiência, adicionar contexto aos erros imediatamente após cada site de chamada é fundamental para ter um código que possa ser facilmente depurado. E os retornos nomeados causaram confusão para quase todos os desenvolvedores de Go que conheço em algum momento.

Uma preocupação menor e estilística é que é lamentável quantas linhas de código agora serão envolvidas em try(actualThing()) . Eu posso imaginar ver a maioria das linhas em uma base de código envolta em try() . Isso parece lamentável.

Acho que essas preocupações seriam abordadas com um ajuste:

a, b, err := myFunc()
check(err, "calling myFunc on %v and %v", a, b)

check() se comportaria como try() , mas descartaria o comportamento de passar pelos valores de retorno da função genericamente e, em vez disso, forneceria a capacidade de adicionar contexto. Ainda provocaria um retorno.

Isso manteria muitas das vantagens de try() :

• é um embutido
• segue o fluxo de controle existente WRT para adiar
• ele se alinha com a prática existente de adicionar contexto aos erros bem
• ele se alinha com as propostas e bibliotecas atuais para quebra de erros, como errors.Wrap(err, "context message")
• resulta em um site de chamadas limpo: não há clichê na linha a, b, err := myFunc()
• descrever erros com defer fmt.HandleError(&err, "msg") ainda é possível, mas não precisa ser encorajado.
• a assinatura de check é um pouco mais simples, porque não precisa retornar um número arbitrário de argumentos da função que está envolvendo.

@s4n-gt Obrigado por este link. Eu não estava ciente disso.

@Goodwine Ponto tomado. A razão para não fornecer suporte mais direto ao tratamento de erros é discutida em detalhes no documento de design. Também é um fato que ao longo de um ano ou mais (desde os projetos de projetos publicados na Gophercon do ano passado) nenhuma solução satisfatória para o tratamento explícito de erros surgiu. É por isso que esta proposta deixa isso de fora de propósito (e sugere usar um defer ). Esta proposta ainda deixa a porta aberta para futuras melhorias nesse sentido.

A proposta menciona a mudança de teste de pacote para permitir que testes e benchmarks retornem um erro. Embora não seja “uma modesta mudança de biblioteca”, poderíamos considerar aceitar func main() error também. Isso tornaria a escrita de pequenos scripts muito mais agradável. A semântica seria equivalente a:

func main() {
  if err := newmain(); err != nil {
    println(err.Error())
    os.Exit(1)
  }
}

Uma última crítica. Não é propriamente uma crítica à proposta em si, mas sim uma crítica a uma resposta comum ao contra-argumento "função controladora do fluxo".

A resposta para "Eu não gosto que uma função esteja controlando o fluxo" é que " panic também controla o fluxo do programa!". No entanto, existem algumas razões pelas quais é mais correto panic fazer isso que não se aplicam a try .

1. panic é amigável para programadores iniciantes porque o que ele faz é intuitivo, ele continua desempacotando a pilha. Não se deve nem ter que pesquisar como panic funciona para entender o que ele faz. Programadores iniciantes nem precisam se preocupar com recover , já que os iniciantes normalmente não estão construindo mecanismos de recuperação de pânico, especialmente porque eles são quase sempre menos favoráveis ​​do que simplesmente evitar o pânico em primeiro lugar.

2. panic é um nome fácil de ver. Isso traz preocupação, e precisa. Se alguém vir panic em uma base de código, deve estar pensando imediatamente em como _evitar_ o pânico, mesmo que seja trivial.

3. Pegando carona no último ponto, panic não pode ser aninhado em uma chamada, tornando ainda mais fácil de ver.

Não há problema em que o pânico controle o fluxo do programa porque é extremamente fácil de detectar e é intuitivo quanto ao que faz.

A função try não satisfaz nenhum desses pontos.

1. Não se pode adivinhar o que try faz sem consultar a documentação. Muitos idiomas usam a palavra-chave de maneiras diferentes, dificultando a compreensão do que isso significaria em Go.

2. try não me chama a atenção, principalmente quando é uma função. _Especialmente_ quando o realce de sintaxe a destacará como uma função. _ESPECIALMENTE_ depois de desenvolver em uma linguagem como Java, onde try é visto como um clichê desnecessário (por causa das exceções verificadas).

3. try pode ser usado em um argumento para uma chamada de função, conforme meu exemplo no meu comentário anterior proc := try(os.FindProcess(try(strconv.Atoi(os.Args[1])))) . Isso torna ainda mais difícil de detectar.

Meus olhos ignoram as funções try , mesmo quando estou procurando especificamente por elas. Meus olhos vão vê-los, mas imediatamente saltam para as chamadas os.FindProcess ou strconv.Atoi . try é um retorno condicional. O fluxo de controle E os retornos são mantidos em pedestais em Go. Todo o fluxo de controle dentro de uma função é recuado e todos os retornos começam com return . Misturar esses dois conceitos em uma chamada de função fácil de perder parece um pouco estranho.

Este comentário e meu último são minhas únicas críticas reais à ideia. Acho que não estou gostando dessa proposta, mas ainda acho que é uma vitória geral para Go. Esta solução ainda parece mais Go do que as outras soluções. Se isso fosse adicionado eu ficaria feliz, mas acho que ainda pode ser melhorado, só não sei como.

@buchanae interessante. Conforme escrito, porém, ele move a formatação no estilo fmt de um pacote para a própria linguagem, o que abre uma lata de worms.

Conforme escrito, porém, ele move a formatação no estilo fmt de um pacote para a própria linguagem, o que abre uma lata de worms.

Bom ponto. Um exemplo mais simples:

a, b, err := myFunc()
check(err, "calling myFunc")

@buchanae Consideramos tornar o tratamento de erros explícito mais diretamente conectado a try - consulte o documento de design detalhado, especificamente a seção sobre iterações de design. Sua sugestão específica de check só permitiria aumentar os erros por meio de algo como fmt.Errorf como API (como parte do check ), se entendi corretamente. Em geral, as pessoas podem querer fazer todos os tipos de coisas com erros, não apenas criar um novo que se refira ao original por meio de sua string de erro.

Novamente, esta proposta não tenta resolver todas as situações de tratamento de erros. Suspeito que na maioria dos casos try faça sentido para o código que agora se parece basicamente com isso:

a, b, c, ... err := try(someFunctionCall())
if err != nil {
   return ..., err
}

Há uma enorme quantidade de código que se parece com isso. E nem todo código que se parece com isso precisa de mais tratamento de erros. E onde defer não está certo, ainda se pode usar uma instrução if .

Eu não sigo esta linha:

defer fmt.HandleErrorf(&err, “foobar”)

Ele descarta o erro de entrada no chão, o que é incomum. É para ser usado algo mais parecido com isso?

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

A duplicação de err é um pouco gagueira. Isso não é realmente diretamente a propósito da proposta, apenas um comentário lateral sobre o documento.

Compartilho as duas preocupações levantadas por @buchanae , re: retornos nomeados e erros contextuais.

Acho os retornos nomeados um pouco problemáticos; Eu acho que eles são realmente benéficos apenas como documentação. Inclinar-se sobre eles com mais força é uma preocupação. Desculpe ser tão vago, no entanto. Vou pensar mais sobre isso e fornecer alguns pensamentos mais concretos.

Eu acho que há uma preocupação real de que as pessoas se esforcem para estruturar seu código para que try possa ser usado e, portanto, evite adicionar contexto aos erros. Este é um momento particularmente estranho para introduzir isso, já que agora estamos fornecendo melhores maneiras de adicionar contexto a erros por meio de recursos oficiais de encapsulamento de erros.

Eu acho que try conforme proposto torna algum código significativamente melhor. Aqui está uma função que escolhi mais ou menos aleatoriamente da base de código do meu projeto atual, com alguns dos nomes alterados. Estou particularmente impressionado com a forma como try funciona ao atribuir campos de estrutura. (Isso supondo que minha leitura da proposta esteja correta e que isso funcione?)

O código existente:

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        err := dbfile.RunMigrations(db, dbMigrations)
        if err != nil {
                return nil, err
        }
        t := &Thing{
                thingy: thingy,
        }
        t.scanner, err = newScanner(thingy, db, client)
        if err != nil {
                return nil, err
        }
        t.initOtherThing()
        return t, nil
}

Com try :

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        try(dbfile.RunMigrations(db, dbMigrations))
        t := &Thing{
                thingy:  thingy,
                scanner: try(newScanner(thingy, db, client)),
        }
        t.initOtherThing()
        return t, nil
}

Nenhuma perda de legibilidade, exceto talvez que seja menos óbvio que newScanner pode falhar. Mas então em um mundo com try os programadores Go seriam mais sensíveis à sua presença.

@josharian Sobre main retornando um error : Parece-me que sua pequena função auxiliar é tudo o que é necessário para obter o mesmo efeito. Não tenho certeza se a alteração da assinatura de main é justificada.

Em relação ao exemplo "foobar": É apenas um mau exemplo. Eu provavelmente deveria mudar isso. Obrigado por trazê-lo à tona.

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

Na verdade, isso não pode estar certo, porque err será avaliado muito cedo. Existem algumas maneiras de contornar isso, mas nenhuma delas é tão limpa quanto o HandleErrorf original (acho falho). Eu acho que seria bom ter um exemplo trabalhado mais realista ou dois de uma função auxiliar.

EDIT: este bug de avaliação inicial está presente em um exemplo
perto do final do documento:

defer fmt.HandleErrorf(&err, "copy %s %s: %v", src, dst, err)

@adg Sim, try pode ser usado como você está usando em seu exemplo. Deixo seus comentários sobre: ​​os retornos nomeados permanecem como estão.

as pessoas podem querer fazer todos os tipos de coisas com erros, não apenas criar um novo que se refira ao original por meio de sua string de erro.

try não tenta lidar com todos os tipos de coisas que as pessoas querem fazer com erros, apenas aquelas que podemos encontrar uma maneira prática de tornar significativamente mais simples. Eu acredito que meu exemplo check caminha na mesma linha.

Na minha experiência, a forma mais comum de código de tratamento de erros é o código que essencialmente adiciona um rastreamento de pilha, às vezes com contexto adicionado. Descobri que o rastreamento de pilha é muito importante para depuração, onde sigo uma mensagem de erro pelo código.

Mas, talvez outras propostas adicionem rastreamentos de pilha a todos os erros? Perdi o rumo.

No exemplo que @adg deu, há duas falhas em potencial, mas nenhum contexto. Se newScanner e RunMigrations não fornecerem mensagens que indiquem qual delas deu errado, então você fica adivinhando.

No exemplo que @adg deu, há duas falhas em potencial, mas nenhum contexto. Se newScanner e RunMigrations não fornecerem mensagens que indiquem qual deu errado, então você ficará adivinhando.

Isso mesmo, e essa é a escolha de design que fizemos neste trecho de código em particular. Envolvemos muitos erros em outras partes do código.

Compartilho a preocupação como @deanveloper e outros de que isso pode dificultar a depuração. É verdade que podemos optar por não usá-lo, mas os estilos de dependências de terceiros não estão sob nosso controle.
Se if err := ... { return err } menos repetitivo for o ponto principal, me pergunto se um "retorno condicional" seria suficiente, como https://github.com/golang/go/issues/27794 proposto.

        return nil, err if f, err := os.Open(...)
        return nil, err if _, err := os.Write(...)

Eu acho que o ? seria um ajuste melhor do que try , e sempre ter que perseguir o defer por erro também seria complicado.

Isso também fecha as portas para exceções usando try/catch para sempre.

Isso também fecha as portas para exceções usando try/catch para sempre.

Estou _mais_ do que bem com isso.

Concordo com algumas das preocupações levantadas acima sobre adicionar contexto a um erro. Estou lentamente tentando mudar de apenas retornar um erro para sempre decorá-lo com um contexto e depois devolvê-lo. Com esta proposta, terei que mudar completamente minha função para usar parâmetros de retorno nomeados (o que acho estranho porque quase não uso retornos nu).

Como diz @griesemer :

Novamente, esta proposta não tenta resolver todas as situações de tratamento de erros. Suspeito que, na maioria dos casos, tente fazer sentido para o código que agora se parece basicamente com isso:
a, b, c, ... err := try(someFunctionCall())
se errar != nil {
voltar..., errar
}
Há uma enorme quantidade de código que se parece com isso. E nem todo código que se parece com isso precisa de mais tratamento de erros. E onde defer não está certo, ainda pode-se usar uma instrução if.

Sim, mas não deve ser bom, o código idiomático sempre envolve/decora seus erros? Acredito que é por isso que estamos introduzindo mecanismos refinados de tratamento de erros para adicionar erros de contexto/empacotamento em stdlib. Pelo que vejo, esta proposta parece considerar apenas o caso de uso mais básico.

Além disso, esta proposta aborda apenas o caso de encapsular/decorar vários sites de retorno de erros possíveis em um _único local_, usando parâmetros nomeados com uma chamada defer.

Mas não faz nada para o caso em que é necessário adicionar contextos diferentes a erros diferentes em uma única função. Por exemplo, é muito essencial decorar os erros do banco de dados para obter mais informações sobre de onde eles estão vindo (supondo que não haja rastreamentos de pilha)

Este é um exemplo de um código real que tenho -

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    if err != nil {
        return err
    }
    var res int64
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    if err != nil {
        tx.Rollback()
        return fmt.Errorf("insert table: %w", err)
    }

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    if err != nil {
        tx.Rollback()
        return fmt.Errorf("insert table2: %w", err)
    }
    return tx.Commit()
}

De acordo com a proposta:

Se o aumento ou encapsulamento de erros for desejado, há duas abordagens: Fique com a instrução if testada e comprovada ou, alternativamente, “declare” um manipulador de erros com uma instrução defer:

Acho que isso se enquadrará na categoria de "manter a instrução if testada e comprovada". Espero que a proposta possa ser melhorada para resolver isso também.

Eu sugiro fortemente que a equipe do Go priorize os genéricos , pois é onde o Go ouve mais críticas e espera o tratamento de erros. A técnica de hoje não é tão dolorosa (embora go fmt devesse deixá-la em uma linha).

O conceito try() tem todos os problemas de check de check/handle:

1. Não se lê como Go. As pessoas querem sintaxe de atribuição, sem o teste nil subsequente, pois isso se parece com Go. Treze respostas separadas para checar/manusear sugeriram isso; veja _Temas recorrentes_ aqui:
   https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

   f, #      := os.Open(...) // return on error
   f, #panic := os.Open(...) // panic on error
   f, #hname := os.Open(...) // invoke named handler on error
   // # is any available symbol or unambiguous pair
   

2. O aninhamento de chamadas de função que retornam erros obscurece a ordem das operações e dificulta a depuração. O estado das coisas quando ocorre um erro e, portanto, a sequência de chamadas devem ser claros, mas aqui não é:
   try(step4(try(step1()), try(step3(try(step2())))))
   Agora lembre-se de que a linguagem proíbe:
   f(t ? a : b) e f(a++)

3. Seria trivial retornar erros sem contexto. Um dos principais fundamentos da verificação/manuseio foi encorajar a contextualização.

4. Está vinculado ao tipo error e ao último valor de retorno. Se precisarmos inspecionar outros valores/tipos de retorno para estado excepcional, voltaremos a: if errno := f(); errno != 0 { ... }

5. Não oferece vários caminhos. O código que chama APIs de armazenamento ou rede trata esses erros de maneira diferente daqueles devidos a entrada incorreta ou estado interno inesperado. Meu código faz um desses com muito mais frequência do que return err :

   • log.Fatal()
   • panic() para erros que nunca deveriam surgir
   • registre uma mensagem e tente novamente

@gopherbot adicionar Go2, LanguageChange

Que tal usar apenas ? para desembrulhar o resultado como rust

A razão pela qual somos céticos sobre chamar try() pode ser duas ligações implícitas. Não podemos ver a ligação para o erro do valor de retorno e os argumentos para try(). Para sobre try(), podemos fazer uma regra que devemos usar try() com função de argumento que tem erro nos valores de retorno. Mas a vinculação a valores de retorno não é. Então, estou pensando que mais expressão é necessária para que os usuários entendam o que esse código está fazendo.

func doSomething() (int, %error) {
  f := try(foo())
  ...
}

• Não podemos usar try() se doSomething não tiver %error em valores de retorno.
• Não podemos usar try() se foo() não tiver erro no último dos valores de retorno.

É difícil adicionar novos requisitos/recursos à sintaxe existente.

Para ser honesto, acho que foo() também deveria ter %error.

Adicionar mais 1 regra

• %error pode ser apenas um na lista de valores de retorno de uma função.

No documento de design detalhado, notei que em uma iteração anterior foi sugerido passar um manipulador de erros para a função try incorporada. Assim:

handler := func(err error) error {
        return fmt.Errorf("foo failed: %v", err)  // wrap error
}

f := try(os.Open(filename), handler)  

ou melhor ainda, assim:

f := try(os.Open(filename), func(err error) error {
        return fmt.Errorf("foo failed: %v", err)  // wrap error
})  

Embora, como o documento afirma, isso levanta várias questões, acho que esta proposta seria muito mais desejável e útil se mantivesse essa possibilidade de especificar opcionalmente essa função ou fechamento de manipulador de erros.

Em segundo lugar, não me importo que um built-in possa fazer com que a função retorne, mas, para diminuir um pouco, o nome 'try' é muito curto para sugerir que pode causar um retorno. Então um nome mais longo, como attempt parece melhor para mim.

EDIT: Em terceiro lugar, idealmente, a linguagem go deve ganhar os genéricos primeiro, onde um caso de uso importante seria a capacidade de implementar essa função try como um genérico, para que o bikeshedding possa terminar e todos possam obter o tratamento de erros que preferirem.

As notícias de hackers têm algum ponto: try não se comporta como uma função normal (pode retornar), então não é bom fornecer uma sintaxe semelhante a uma função. Uma sintaxe return ou defer seria mais apropriada:

func CopyFile(src, dst string) (err error) {
        r := try os.Open(src)
        defer r.Close()

        w := try os.Create(dst)
        defer func() {
                w.Close()
                if err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        try io.Copy(w, r)
        try w.Close()
        return nil
}

@sheerun o contra-argumento comum para isso é que panic também é uma função interna que altera o fluxo de controle. Eu pessoalmente discordo disso, mas está correto.

1. Ecoando @deanveloper acima , bem como comentários semelhantes de outras pessoas, temo que estejamos subestimando os custos de adicionar uma palavra-chave nova, um tanto sutil e - especialmente quando incorporada em outras chamadas de função - facilmente ignorada que gerencia o controle da pilha de chamadas fluxo. panic(...) é uma exceção relativamente clara (trocadilho não intencional) à regra de que return é a única saída para uma função. Eu não acho que devemos usar sua existência como justificativa para adicionar um terceiro.
2. Essa proposta canonizaria o retorno de um erro não encapsulado como o comportamento padrão e relegaria os erros de encapsulamento como algo que você precisa aceitar, com cerimônia adicional. Mas, na minha experiência, isso é precisamente o contrário das boas práticas. Espero que uma proposta neste espaço torne mais fácil, ou pelo menos não mais difícil, adicionar informações contextuais aos erros no local do erro.

talvez possamos adicionar uma variante com função de aumento opcional algo como tryf com esta semântica:

func tryf(t1 T1, t1 T2, … tn Tn, te error, fn func(error) error) (T1, T2, … Tn)

traduz isso

x1, x2, … xn = tryf(f(), func(err error) { return fmt.Errorf("foobar: %q", err) })

nisso

t1, … tn, te := f()
if te != nil {
    if fn != nil {
        te = fn(te)
    }
    err = te
    return
}

uma vez que esta é uma escolha explícita (em vez de usar try ), podemos encontrar respostas razoáveis ​​às perguntas na versão anterior deste design. por exemplo, se a função de aumento for nula, não faça nada e apenas retorne o erro original.

Estou preocupado que try suplantará o tratamento de erros tradicional e, como resultado, tornará a anotação de caminhos de erro mais difícil.

O código que lida com erros registrando mensagens e atualizando contadores de telemetria será considerado defeituoso ou impróprio por linters e desenvolvedores que esperam try tudo.

a, b, err := doWork()
if err != nil {
  updateCounters()
  writeLogs()
  return err
}

Go é uma linguagem extremamente social com expressões idiomáticas comuns impostas por ferramentas (fmt, lint, etc). Por favor, mantenha as ramificações sociais desta ideia em mente - haverá uma tendência de querer usá-la em todos os lugares.

@politician , desculpe, mas a palavra que você está procurando não é _social_, mas _opinionated_. Go é uma linguagem de programação opinativa. De resto, concordo em grande parte com o que você quer dizer.

Ferramentas da comunidade @beoran como Godep e os vários linters demonstram que Go é tanto opinativo quanto social, e muitos dos dramas com a linguagem derivam dessa combinação. Felizmente, nós dois podemos concordar que try não deve ser o próximo drama.

@politician Obrigado por esclarecer, eu não tinha entendido dessa maneira. Posso certamente concordar que devemos tentar evitar o drama.

Estou confuso sobre isso.

Do blog: Erros são valores , na minha perspectiva, foi feito para ser valorizado e não para ser ignorado.

E eu acredito no que Rop Pike disse: "Valores podem ser programados, e como erros são valores, erros podem ser programados".

Não devemos considerar error como exception , é como importar complexidade não apenas para pensar, mas também para codificar se fizermos isso.

"Use a linguagem para simplificar o tratamento de erros." -- Rob Pike

E mais, podemos rever este slide

Uma situação em que acho a verificação de erros via if particularmente estranha é ao fechar arquivos (por exemplo, em NFS). Eu acho que, atualmente, devemos escrever o seguinte, se os retornos de erro de .Close() forem possíveis?

r, err := os.Open(src)
if err != nil {
    return err
}
defer func() {
    // maybe check whether a previous error occured?
    return r.Close()
}()

defer try(r.Close()) poderia ser uma boa maneira de ter uma sintaxe gerenciável para lidar com esses erros? Pelo menos, faria sentido ajustar o exemplo CopyFile() na proposta de alguma forma, para não ignorar erros de r.Close() e w.Close() .

@seehuhn Seu exemplo não será compilado porque a função adiada não possui um tipo de retorno.

func doWork() (err error) {
  r, err := os.Open(src)
  if err != nil {
    return err
  }
  defer func() {
    err = r.Close()  // overwrite the return value
  }()
}

Vai funcionar como você espera. A chave é o valor de retorno nomeado.

Eu gosto da proposta, mas acho que o exemplo de @seehuhn deve ser abordado também:

defer try(w.Close())

retornaria o erro de Close() somente se o erro ainda não estivesse definido.
Esse padrão é usado com tanta frequência...

Concordo com as preocupações sobre adicionar contexto aos erros. Eu vejo isso como uma das melhores práticas que mantém as mensagens de erro muito amigáveis ​​(e claras) e facilita o processo de depuração.

A primeira coisa que pensei foi substituir o fmt.HandleErrorf por uma função tryf , que prefixa o erro com contexto adicional.

func tryf(t1 T1, t1 T2, … tn Tn, te error, ts string) (T1, T2, … Tn)

Por exemplo (de um código real que tenho):

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil {
        return nil, errors.WithMessage(err, "load config dir")
    }
    b := bytes.NewBuffer(nil)
    if err = templates.ExecuteTemplate(b, "main", c); err != nil {
        return nil, errors.WithMessage(err, "execute main template")
    }
    buf, err := format.Source(b.Bytes())
    if err != nil {
        return nil, errors.WithMessage(err, "format main template")
    }
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    if err := ioutil.WriteFile(target, buf, 0644); err != nil {
        return nil, errors.WithMessagef(err, "write file %s", target)
    }
    // ...
}

Pode ser alterado para algo como:

func (c *Config) Build() error {
    pkgPath := tryf(c.load(), "load config dir")
    b := bytes.NewBuffer(nil)
    tryf(emplates.ExecuteTemplate(b, "main", c), "execute main template")
    buf := tryf(format.Source(b.Bytes()), "format main template")
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    tryf(ioutil.WriteFile(target, buf, 0644), fmt.Sprintf("write file %s", target))
    // ...
}

Ou, se eu pegar o exemplo de @agnivade :

func (p *pgStore) DoWork() (err error) {
    tx := tryf(p.handle.Begin(), "begin transaction")
        defer func() {
        if err != nil {
            tx.Rollback()
        }
    }()
    var res int64
    tryf(tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res), "insert table")
    _, = tryf(tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res), "insert table2")
    return tryf(tx.Commit(), "commit transaction")
}

No entanto, @josharian levantou um bom ponto que me faz hesitar nesta solução:

Conforme escrito, porém, ele move a formatação no estilo fmt de um pacote para a própria linguagem, o que abre uma lata de worms.

Estou totalmente de acordo com esta proposta e posso ver seus benefícios em vários exemplos.

Minha única preocupação com a proposta é a nomenclatura de try , sinto que suas conotações com outras linguagens, podem distorcer a percepção dos desenvolvedores de qual é o seu propósito ao vir de outras linguagens. Java vem encontrar aqui.

Para mim, eu preferiria que o builtin fosse chamado pass . Eu sinto que isso dá uma melhor representação do que está acontecendo. Afinal, você não está lidando com o erro - em vez disso, devolvendo-o para ser tratado pelo chamador. try dá a impressão de que o erro foi tratado.

É um polegar para baixo de mim, principalmente porque o problema que ele visa resolver ("as instruções if clichê normalmente associadas ao tratamento de erros") simplesmente não é um problema para mim. Se todas as verificações de erro fossem simplesmente if err != nil { return err } , então eu poderia ver algum valor em adicionar açúcar sintático para isso (embora Go seja uma linguagem relativamente livre de açúcar por inclinação).

Na verdade, o que eu quero fazer no caso de um erro não nulo varia consideravelmente de uma situação para outra. Talvez eu queira t.Fatal(err) . Talvez eu queira adicionar uma mensagem de decoração return fmt.Sprintf("oh no: %v", err) . Talvez eu apenas registre o erro e continue. Talvez eu defina um sinalizador de erro no meu objeto SafeWriter e continue, verificando o sinalizador no final de alguma sequência de operações. Talvez eu precise tomar algumas outras ações. Nenhum deles pode ser automatizado com try . Portanto, se o argumento para try for que ele eliminará todos os blocos if err != nil , esse argumento não se sustenta.

Será que vai eliminar _some_ deles? Certo. Essa é uma proposta atraente para mim? Meh. Eu realmente não estou preocupado. Para mim, if err != nil é apenas parte do Go, como as chaves, ou defer . Eu entendo que parece verboso e repetitivo para as pessoas que são novas em Go, mas as pessoas que são novas em Go não estão em melhor posição para fazer mudanças dramáticas no idioma, por vários motivos.

A barreira para mudanças significativas no Go tem sido tradicionalmente que a mudança proposta deve resolver um problema que é (A) significativo, (B) afeta muitas pessoas e (C) é bem resolvido pela proposta. Não estou convencido de nenhum desses três critérios. Estou muito feliz com o tratamento de erros do Go.

Para repetir @peterbourgon e @deanveloper , uma das minhas coisas favoritas sobre Go é que o fluxo de código é claro e panic() não é tratado como um mecanismo de controle de fluxo padrão da maneira que é em Python.

Em relação ao debate sobre o pânico, panic() quase sempre aparece sozinho em uma linha porque não tem valor. Você não pode fmt.Println(panic("oops")) . Isso aumenta sua visibilidade tremendamente e o torna muito menos comparável a try() do que as pessoas estão imaginando.

Se houver outra construção de controle de fluxo para funções, eu preferiria _muito_ que fosse uma instrução garantida para ser o item mais à esquerda em uma linha.

Um dos exemplos na proposta resolve o problema para mim:

func printSum(a, b string) error {
        fmt.Println(
                "result:",
                try(strconv.Atoi(a)) + try(strconv.Atoi(b)),
        )
        return nil
}

O fluxo de controle realmente se torna menos óbvio e muito obscurecido.

Isso também vai contra a intenção inicial de Rob Pike de que todos os erros precisam ser tratados explicitamente.

Embora uma reação a isso possa ser "então não o use", o problema é -- outras bibliotecas o usarão, e depurá-los, lê-los e usá-los se torna mais problemático. Isso motivará minha empresa a nunca adotar o go 2 e começar a usar apenas bibliotecas que não usam try . Se eu não estiver sozinho com isso, pode levar a uma divisão a-la python 2/3.

Além disso, a nomeação de try implicará automaticamente que eventualmente catch aparecerá na sintaxe e voltaremos a ser Java.

Então, por tudo isso, sou _fortemente_ contra essa proposta.

Eu não gosto do nome try . Isso implica uma _tentativa_ de fazer algo com alto risco de falha (posso ter um viés cultural contra _tentar_ já que não sou um falante nativo de inglês), enquanto try seria usado no caso de esperarmos falhas raras (motivação para querer reduzir a verbosidade do tratamento de erros) e são otimistas. Além disso try nesta proposta de fato _captura_ um erro ao devolvê-lo antecipadamente. Gostei da sugestão pass do @HiImJC.

Além do nome, acho estranho ter return -como a declaração agora escondida no meio das expressões. Isso quebra o estilo de fluxo Go. Isso tornará as revisões de código mais difíceis.

Em geral, acho que esta proposta só beneficiará o programador preguiçoso que agora tem uma arma para código mais curto e ainda menos motivos para fazer o esforço de encapsular erros. Como também dificultará as revisões (retorno no meio da expressão), acho que essa proposta vai contra o objetivo de "programação em escala" do Go.

Uma das minhas coisas favoritas sobre Go que geralmente digo ao descrever a linguagem é que só há uma maneira de fazer as coisas, para a maioria das coisas. Esta proposta vai um pouco contra esse princípio ao oferecer várias maneiras de fazer a mesma coisa. Pessoalmente, acho que isso não é necessário e que tiraria, em vez de aumentar a simplicidade e a legibilidade da linguagem.

Eu gosto desta proposta em geral. A interação com defer parece suficiente para fornecer uma maneira ergonômica de retornar um erro ao mesmo tempo em que adiciona contexto adicional. Embora seja bom resolver o problema que @josharian apontou sobre como incluir o erro original na mensagem de erro encapsulada.

O que está faltando é uma forma ergonômica de interagir com a(s) proposta(s) de inspeção de erros na mesa. Acredito que as APIs devem ser muito deliberadas em quais tipos de erros eles retornam, e o padrão provavelmente deve ser "os erros retornados não são inspecionáveis ​​de forma alguma". Deve então ser fácil ir para um estado em que os erros sejam inspecionáveis ​​de maneira precisa, conforme documentado pela assinatura da função ("Relata um erro do tipo X na circunstância A e um erro do tipo Y na circunstância B").

Infelizmente, a partir de agora, esta proposta torna a opção mais ergonômica a mais indesejável (para mim); passando cegamente por tipos de erros arbitrários. Acho que isso é indesejável porque incentiva a não pensar nos tipos de erros que você retorna e como os usuários de sua API os consumirão. A conveniência adicional desta proposta é certamente boa, mas temo que encoraje o mau comportamento porque a conveniência percebida superará o valor percebido de pensar cuidadosamente sobre quais informações de erro você fornece (ou vaza).

Um bandaid seria se os erros retornados por try fossem convertidos em erros que não fossem "desempacotados". Infelizmente, isso também tem desvantagens bastante graves, pois faz com que qualquer defer não possa inspecionar os erros em si. Além disso, evita o uso em que try realmente retornará um erro de um tipo desejável (ou seja, casos de uso em que try é usado com cuidado e não descuidadamente).

Outra solução seria redirecionar a ideia (descartada) de ter um segundo argumento opcional para try para definir/lista branca do(s) tipo(s) de erro que podem ser retornados desse site. Isso é um pouco problemático porque temos duas maneiras diferentes de definir um "tipo de erro", seja por valor ( io.EOF etc) ou por tipo ( *os.PathError , *exec.ExitError ). É fácil especificar tipos de erro que são valores como argumentos para uma função, mas é mais difícil especificar tipos. Não tenho certeza de como lidar com isso, mas jogando a ideia lá fora.

O problema que @josharian apontou pode ser evitado atrasando a avaliação de err:

defer func() { fmt.HandleErrorf(&err, "oops: %v", err) }()

Não parece ótimo, mas deve funcionar. Eu preferiria, no entanto, que isso pudesse ser resolvido adicionando um novo verbo/sinalizador de formatação para ponteiros de erro, ou talvez para ponteiros em geral, que imprima o valor desreferenciado como com %v . Para o propósito do exemplo, vamos chamá-lo de %*v :

defer fmt.HandleErrorf(&err, "oops: %*v", &err)

O problema à parte, acho que esta proposta parece promissora, mas parece crucial manter a ergonomia de adicionar contexto aos erros sob controle.

Editar:

Outra abordagem é envolver o ponteiro de erro em uma estrutura que implementa Stringer :

type wraperr struct{ err *error }
func (w wraperr) String() string { return (*w.err).Error() }

...

defer handleErrorf(&err, "oops: %v", wraperr{&err})

Algumas coisas da minha perspectiva. Por que estamos tão preocupados em salvar algumas linhas de código? Eu considero isso na mesma linha que as pequenas funções consideradas prejudiciais .

Além disso, acho que tal proposta removeria a responsabilidade de lidar corretamente com o erro para alguma "mágica" que eu me preocupo que seja abusada e encorajaria a preguiça, resultando em código de baixa qualidade e bugs.

A proposta, conforme declarado, também tem vários comportamentos pouco claros, então isso já é problemático do que um _explícito_ extra ~ 3 linhas que são mais claras.

Atualmente, usamos o padrão de diferimento com moderação em casa. Há um artigo aqui que teve uma recepção igualmente mista quando o escrevemos - https://bet365techblog.com/better-error-handling-in-go

No entanto, nosso uso foi em antecipação ao progresso da proposta check / handle .

Check/handle era uma abordagem muito mais abrangente para tornar o tratamento de erros mais conciso. Seu bloco handle manteve o mesmo escopo de função daquele em que foi definido, enquanto quaisquer instruções defer são novos contextos com uma quantidade, por mais que seja, de sobrecarga. Isso parecia estar mais de acordo com as expressões idiomáticas de go, pois se você quisesse o comportamento de "apenas retorne o erro quando acontecer", você poderia declarar isso explicitamente como handle { return err } .

Defer obviamente depende da manutenção da referência de erro também, mas vimos problemas surgirem ao sombrear a referência de erro com vars com escopo de bloco. Portanto, não é infalível o suficiente para ser considerado a maneira padrão de lidar com erros em andamento.

try , neste caso, não parece resolver muito e eu compartilho do mesmo medo que outros de que isso simplesmente levaria a implementações preguiçosas, ou aquelas que usam excessivamente o padrão defer.

Se o tratamento de erros baseado em adiar for A Thing, algo assim provavelmente deve ser adicionado ao pacote de erros:

        f := try(os.Create(filename))
        defer errors.Deferred(&err, f.Close)

Ignorar os erros de instruções Close adiadas é um problema bastante comum. Deve haver uma ferramenta padrão para ajudar com isso.

Uma função interna que retorna é mais difícil de vender do que uma palavra-chave que faz o mesmo.
Eu gostaria mais se fosse uma palavra-chave como está em Zig[1].

1. https://ziglang.org/documentation/master/#try

Funções embutidas, cuja assinatura de tipo não pode ser expressa usando o sistema de tipos da linguagem e cujo comportamento confunde o que uma função normalmente é, parece apenas uma escotilha de escape que pode ser usada repetidamente para evitar a evolução real da linguagem.

Estamos acostumados a reconhecer imediatamente declarações de retorno (e pânico) porque é assim que esse tipo de fluxo de controle é expresso em Go (e muitas outras linguagens). Não parece muito improvável que também reconheçamos try como alterar o fluxo de controle depois de nos acostumarmos a ele, assim como fazemos para return. Não tenho dúvidas de que um bom suporte IDE também ajudará nisso.

Eu acho que é bastante rebuscado. No código gofmt'ed, um retorno sempre corresponde /^\t*return / – é um padrão muito trivial para detectar a olho nu, sem qualquer assistência. try , por outro lado, pode ocorrer em qualquer lugar no código, aninhado arbitrariamente nas chamadas de função. Nenhuma quantidade de treinamento nos tornará capazes de identificar imediatamente todo o fluxo de controle em uma função sem a ajuda da ferramenta.

Além disso, um recurso que depende de "bom suporte a IDE" estará em desvantagem em todos os ambientes onde não houver um bom suporte a IDE. As ferramentas de revisão de código vêm à mente imediatamente – Gerrit destacará todas as tentativas para mim? E as pessoas que optam por não usar IDEs, ou realce de código sofisticado, por vários motivos? A acme começará a destacar try ?

Um recurso de linguagem deve ser fácil de entender por si só, não depender do suporte do editor.

@kungfusheep Eu gosto desse artigo. Cuidar de embrulhar em um defer sozinho já aumenta bastante a legibilidade sem try .

Estou no campo que não acha que erros no Go são realmente um problema. Mesmo assim, if err != nil { return err } pode ser bastante gaguejante em algumas funções. Eu escrevi funções que precisavam de uma verificação de erro após quase todas as instruções e nenhuma precisava de nenhum tratamento especial além de wrap e return. Às vezes, simplesmente não há nenhuma estrutura de buffer inteligente que torne as coisas mais agradáveis. Às vezes, é apenas um passo crítico diferente após o outro e você precisa simplesmente dar um curto-circuito se algo der errado.

Embora try certamente tornaria esse código muito mais fácil de ler, sendo totalmente compatível com versões anteriores, concordo que try não é um recurso essencial obrigatório, portanto, se as pessoas tiverem muito medo de talvez seja melhor não tê-lo.

A semântica é bastante clara embora. Sempre que você vê try ou está seguindo o caminho feliz, ou retorna. Eu realmente não posso ficar mais simples do que isso.

Isso se parece com uma macro em maiúsculas especial.

@dominikh try sempre corresponde /try\(/ então não sei qual é realmente o seu ponto. É igualmente pesquisável e todos os editores de que já ouvi falar têm um recurso de pesquisa.

@qrpnxz Acho que o ponto que ele estava tentando fazer não é que você não possa procurá-lo programaticamente, mas que é mais difícil procurar com os olhos. O regexp era apenas uma analogia, com ênfase no /^\t* , significando que todos os retornos se destacam claramente por estarem no início de uma linha (ignorando os espaços em branco iniciais).

Pensando mais sobre isso, deve haver algumas funções auxiliares comuns. Talvez eles devam estar em um pacote chamado "adiado".

Abordando a proposta de um check com formato para evitar nomear o retorno, você pode fazer isso apenas com uma função que verifica nil, assim

func Format(err error, message string, args ...interface{}) error {
    if err == nil {
        return nil
    }
    return fmt.Errorf(...)
}

Isso pode ser usado sem um retorno nomeado assim:

func foo(s string) (int, error) {
    n, err := strconv.Atoi(s)
    try(deferred.Format(err, "bad string %q", s))
    return n, nil
}

O fmt.HandleError proposto poderia ser colocado no pacote adiado e minha função auxiliar errors.Defer poderia ser chamada deferred.Exec e poderia haver um exec condicional para os procedimentos serem executados somente se o erro não for nulo.

Juntando, você obtém algo como

func CopyFile(src, dst string) (err error) {
    defer deferred.Annotate(&err, "copy %s %s", src, dst)

    r := try(os.Open(src))
    defer deferred.Exec(&err, r.Close)

    w := try(os.Create(dst))
    defer deferred.Exec(&err, r.Close)

    defer deferred.Cond(&err, func(){ os.Remove(dst) })
    try(io.Copy(w, r))

    return nil
}

Outro exemplo:

func (p *pgStore) DoWork() (err error) {
    tx := try(p.handle.Begin())

    defer deferred.Cond(&err, func(){ tx.Rollback() })

    var res int64 
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    try(deferred.Format(err, "insert table")

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    try(deferred.Format(err, "insert table2"))

    return tx.Commit()
}

Esta proposta nos leva de ter if err != nil em todos os lugares, para ter try em todos os lugares. Desloca o problema proposto e não o resolve.

Embora, eu argumentaria que o atual mecanismo de tratamento de erros não é um problema para começar. Só precisamos melhorar as ferramentas e a verificação em torno disso.

Além disso, eu argumentaria que if err != nil é realmente mais legível do que try porque não sobrecarrega a linha da linguagem de lógica de negócios, mas fica logo abaixo dela:

file := try(os.OpenFile("thing")) // less readable than, 

file, err := os.OpenFile("thing")
if err != nil {

}

E se Go era para ser mais mágico em seu tratamento de erros, por que não apenas possuí-lo totalmente. Por exemplo, Go pode chamar implicitamente o try interno se um usuário não atribuir um erro. Por exemplo:

func getString() (string, error) { ... }

func caller() {
  defer func() {
    if err != nil { ... } // whether `err` must be defined or not is not shown in this example. 
  }

  // would call try internally, because a user is not 
  // assigning an error value. Also, it can add a compile error
  // for "defined and not used err value" if the user does not 
  // handle the error. 
  str := getString()
}

Para mim, isso realmente resolveria o problema de redundância ao custo de mágica e legibilidade potencial.

Portanto, proponho que realmente resolvamos o 'problema' como no exemplo acima ou mantemos o tratamento de erros atual, mas em vez de alterar o idioma para resolver redundância e encapsulamento, não alteramos o idioma, mas melhoramos as ferramentas e a verificação de código para tornar a experiência melhor.

Por exemplo, no VSCode há um trecho chamado iferr se você digitá-lo e pressionar enter, ele se expande para uma declaração completa de tratamento de erros ... portanto, escrever nunca parece cansativo para mim e ler mais tarde é melhor .

@josharian

Embora não seja “uma mudança modesta na biblioteca”, poderíamos considerar aceitar o erro func main() também.

O problema é que nem todas as plataformas têm uma semântica clara sobre o que isso significa. Sua reescrita funciona bem em programas Go "tradicionais" executados em um sistema operacional completo - mas assim que você escreve o firmware do microcontrolador ou mesmo apenas o WebAssembly, não fica muito claro o que os.Exit(1) significaria. Atualmente, os.Exit é uma chamada de biblioteca, então as implementações Go são gratuitas apenas para não fornecê-la. A forma de main é uma preocupação de linguagem.

Uma pergunta sobre a proposta que provavelmente é melhor respondida por "não": Como try interage com argumentos variáveis? É o primeiro caso de uma função variadic (ish) que não tem seu variadic-nes no último argumento. Isso é permitido:

var e []error
try(e...)

Deixando de lado por que você faria isso. Suspeito que a resposta seja "não" (caso contrário, o acompanhamento é "e se o comprimento da fatia expandida for 0). Apenas trazendo isso à tona para que possa ser lembrado ao formular a especificação eventualmente.

• Vários dos maiores recursos em go são que os internos atuais garantem um fluxo de controle claro, o tratamento de erros é explícito e incentivado e os desenvolvedores são fortemente dissuadidos de escrever código "mágico". A proposta try não é consistente com esses princípios básicos, pois promoverá taquigrafia ao custo da legibilidade do fluxo de controle.
• Se esta proposta for adotada, talvez considere tornar o try embutido em uma instrução em vez de uma função . Então é mais consistente com outras instruções de fluxo de controle como if . Além disso, a remoção dos parênteses aninhados melhora marginalmente a legibilidade.
• Novamente, se a proposta for adotada, talvez a implemente sem usar defer ou similar. Ele já não pode ser implementado em puro go (como apontado por outros), então também pode usar uma implementação mais eficiente sob o capô.

Vejo dois problemas nisso:

1. Ele coloca MUITO código aninhado dentro de funções. Isso adiciona muita carga cognitiva extra, tentando analisar o código em sua cabeça.

1. Ele nos dá lugares onde o código pode sair do meio de uma instrução.

Número 2 eu acho que é muito pior. Todos os exemplos aqui são chamadas simples que retornam um erro, mas o que é muito mais insidioso é isso:

func doit(abc string) error {
    a := fmt.Sprintf("value of something: %s\n", try(getValue(abc)))
    log.Println(a)
    return nil
}

Esse código pode sair no meio desse sprintf, e será SUPER fácil perder esse fato.

Meu voto é não. Isso não tornará o código Go melhor. Não vai facilitar a leitura. Não vai torná-lo mais robusto.

Eu já disse isso antes, e esta proposta exemplifica isso - eu sinto que 90% das reclamações sobre Go são "Eu não quero escrever uma instrução if ou um loop" . Isso remove algumas instruções if muito simples, mas adiciona carga cognitiva e facilita a perda de pontos de saída para uma função.

Eu só quero salientar que você não pode usar isso no main e pode ser confuso para novos usuários ou ao ensinar. Obviamente isso se aplica a qualquer função que não retorne um erro, mas acho que main é especial, pois aparece em muitos exemplos.

func main() {
    f := try(os.Open("foo.txt"))
    defer f.Close()
}

Não tenho certeza se tentar pânico no main também seria aceitável.

Além disso, não seria particularmente útil em testes ( func TestFoo(t* testing.T) ) o que é lamentável :(

O problema que tenho com isso é que você sempre deseja retornar o erro quando isso acontecer. Quando talvez você queira adicionar contexto ao erro e devolvê-lo ou talvez você apenas queira se comportar de maneira diferente quando um erro acontecer. Talvez isso dependa do tipo de erro retornado.

Eu preferiria algo parecido com um try/catch que pode parecer

Assumindo foo() definido como

func foo() (int, error) {}

Você poderia então fazer

n := try(foo()) {
    case FirstError:
        // do something based on FirstError
    case OtherError:
        // do something based on OtherError
    default:
        // default behavior for any other error
}

O que se traduz em

n, err := foo()
if errors.Is(err, FirstError) {
    // do something based on FirstError
if errors.Is(err, OtherError) {
    // do something based on OtherError
} else {
    // default behavior for any other error
}

Para mim, o tratamento de erros é uma das partes mais importantes de uma base de código.
Já muito código go é if err != nil { return err } , retornando um erro do fundo da pilha sem adicionar contexto extra, ou até (possivelmente) pior adicionando contexto mascarando o erro subjacente com quebra fmt.Errorf .

Fornecer uma nova palavra-chave que é uma espécie de mágica que não faz nada além de substituir if err != nil { return err } parece um caminho perigoso a seguir.
Agora todo o código será apenas envolvido em uma chamada para tentar. Isso é um pouco bom (embora a legibilidade seja uma droga) para código que está lidando apenas com erros no pacote, como:

func foo() error {
  /// stuff
  try(bar())
  // more stuff
}

Mas eu diria que o exemplo dado é realmente horrível e basicamente deixa o chamador tentando entender um erro que está muito profundo na pilha, bem como o tratamento de exceções.
Claro, tudo isso depende do desenvolvedor fazer a coisa certa aqui, mas dá ao desenvolvedor uma ótima maneira de não se preocupar com seus erros com talvez um "vamos corrigir isso mais tarde" (e todos nós sabemos como isso acontece ).

Eu gostaria que olhássemos para o problema de uma perspectiva diferente de *"como podemos reduzir a repetição" e mais sobre "como podemos tornar o tratamento de erros (adequado) mais simples e os desenvolvedores mais produtivos".
Devemos estar pensando em como isso afetará a execução do código de produção.

*Nota: Na verdade, isso não reduz a repetição, apenas altera o que está sendo repetido, ao mesmo tempo em que torna o código menos legível porque tudo está dentro de um try() .

Um último ponto: Ler a proposta no começo parece legal, depois você começa a se meter em todas as pegadinhas (pelo menos as listadas) e é tipo “ok sim, isso é demais”.

Percebo que muito disso é subjetivo, mas é algo com o qual me importo. Essas semânticas são incrivelmente importantes.
O que eu quero ver é uma maneira de tornar a escrita e a manutenção do código de nível de produção mais simples, de modo que você também possa fazer erros "certos" mesmo para código de nível POC/demo.

Como o contexto de erro parece ser um tema recorrente...

Hipótese: a maioria das funções Go retorna (T, error) em oposição a (T1, T2, T3, error)

E se, ao invés de definir try como try(T1, T2, T3, error) (T1, T2, T3) nós o definissemos como
try(func (args) (T1, T2, T3, error))(T1, T2, T3) ? (isso é uma aproximação)

o que quer dizer que a estrutura sintática de uma chamada try é sempre um primeiro argumento que é uma expressão que retorna vários valores, sendo o último um erro.

Então, assim como make , isso abre a porta para uma forma de 2 argumentos da chamada, onde o segundo argumento é o contexto da tentativa (por exemplo, uma string fixa, uma string com %v , uma função que recebe um argumento de erro e retorna outro erro etc.)

Isso ainda permite o encadeamento para o caso (T, error) , mas você não pode mais encadear vários retornos que o IMO normalmente não é necessário.

@ cpuguy83 Se você ler a proposta, verá que não há nada impedindo que você envolva o erro. Na verdade, existem várias maneiras de fazer isso enquanto ainda estiver usando try . Muitas pessoas parecem supor que por algum motivo.

if err != nil { return err } é tão "vamos corrigir isso mais tarde" quanto try exceto mais irritante ao prototipar.

Eu não sei como as coisas dentro de um par de parênteses são menos legíveis do que as etapas de função a cada quatro linhas de clichê.

Seria bom se você apontasse algumas dessas "pegadinhas" em particular que o incomodaram, já que esse é o tópico.

A legibilidade parece ser um problema, mas que tal ir fmt apresentando try() para que se destaque, algo como:

f := try(
    os.Open("file.txt")
)

@MrTravisB

O problema que tenho com isso é que você sempre deseja retornar o erro quando isso acontecer.

Discordo. Ele pressupõe que você deseja fazer isso com frequência suficiente para justificar uma abreviação para isso. Se você não fizer isso, isso não atrapalha o tratamento de erros claramente.

Quando talvez você queira adicionar contexto ao erro e devolvê-lo ou talvez você apenas queira se comportar de maneira diferente quando um erro acontecer.

A proposta descreve um padrão para adicionar contexto de todo o bloco aos erros. @josharian apontou que há um erro nos exemplos, porém, e não está claro qual é a melhor maneira de evitá-lo. Eu escrevi alguns exemplos de maneiras de lidar com isso.

Para um contexto de erro mais específico, novamente, try faz uma coisa, e se você não quiser essa coisa, não use try .

@boomlinde Exatamente meu ponto. Esta proposta está tentando resolver um caso de uso singular em vez de fornecer uma ferramenta para resolver o problema maior de tratamento de erros. Eu acho que a questão fundamental é exatamente o que você apontou.

Ele pressupõe que você deseja fazer isso com frequência suficiente para justificar uma abreviação para isso.

Na minha opinião e experiência, este caso de uso é uma pequena minoria e não garante sintaxe abreviada.

Além disso, a abordagem de usar defer para lidar com erros tem problemas, pois pressupõe que você deseja lidar com todos os erros possíveis da mesma forma. As declarações defer não podem ser canceladas.

defer fmt.HandleErrorf(&err, “foobar”)

n := try(foo())

x : try(foo2())

E se eu quiser um tratamento de erros diferente para erros que podem ser retornados de foo() vs foo2() ?

@MrTravisB

E se eu quiser um tratamento de erro diferente para erros que podem ser retornados de foo() vs foo2()?

Então você usa outra coisa. Esse é o ponto que @boomlinde estava fazendo.

Talvez você pessoalmente não veja esse caso de uso com frequência, mas muitas pessoas o fazem, e adicionar try realmente não afeta você. Na verdade, quanto mais raro o caso de uso for para você, menos afetará você que try seja adicionado.

@qrpnxz

f := try(os.Open("/foo"))
data := try(ioutil.ReadAll(f))
try(send(data))

(sim, eu entendo que existe ReadFile e que este exemplo em particular não é a melhor maneira de copiar dados em algum lugar, não é o ponto)

Isso exige mais esforço para ler porque você precisa analisar o inline do try. A lógica do aplicativo é encerrada em outra chamada.
Eu também argumentaria que um manipulador de erro defer aqui não seria bom, exceto para apenas envolver o erro com uma nova mensagem ... o que é bom, mas há mais para lidar com erros do que facilitar para o humano para ler o que aconteceu.

Na ferrugem, pelo menos, o operador é um postfix ( ? adicionado ao final de uma chamada) que não coloca um fardo extra para desenterrar a lógica real.

Controle de fluxo baseado em expressão

panic pode ser outra função de controle de fluxo, mas não retorna um valor, tornando-se efetivamente uma declaração. Compare isso com try , que é uma expressão e pode ocorrer em qualquer lugar.

recover tem um valor e afeta o controle de fluxo, mas deve ocorrer em uma instrução defer . Esses defer s normalmente são literais de função, recover é chamado apenas uma vez e, portanto, recover também ocorre efetivamente como uma instrução. Novamente, compare isso com try que pode ocorrer em qualquer lugar.

Acho que esses pontos significam que try torna significativamente mais difícil seguir o fluxo de controle de uma maneira que não tínhamos antes, como foi apontado antes, mas não vi a distinção entre instruções e expressões apontou.

Outra proposta

Permitir declarações como

if err != nil {
    return nil, 0, err
}

para ser formatado em uma linha por gofmt quando o bloco contém apenas uma instrução return e essa instrução não contém novas linhas. Por exemplo:

if err != nil { return nil, 0, err }

Justificativa

• Não requer alterações de idioma
• A regra de formatação é simples e clara
• A regra pode ser projetada para ser opt-in onde gofmt mantém novas linhas se elas já existirem (como literais de estrutura). Optar também permite que o escritor faça com que algum tratamento de erros seja enfatizado
• Se não for opt-in, o código pode ser portado automaticamente para o novo estilo com uma chamada para gofmt
• É apenas para declarações de return , para que não seja usado desnecessariamente o código de golfe
• Interage bem com comentários que descrevem por que alguns erros podem ocorrer e por que eles estão sendo retornados. Usar muitas expressões try aninhadas lida com isso mal
• Reduz o espaço vertical de tratamento de erros em 66%
• Sem fluxo de controle baseado em expressão
• O código é lido com muito mais frequência do que escrito, por isso deve ser otimizado para o leitor. Código repetitivo ocupando menos espaço é útil para o leitor, onde try se inclina mais para o escritor
• As pessoas já propuseram try existentes em várias linhas. Por exemplo, este comentário ou este comentário que introduz um estilo como

f, err := os.Open(file)
try(maybeWrap(err))

• O estilo "experimentar em sua própria linha" remove qualquer ambiguidade sobre qual err está sendo retornado. Portanto, suspeito que este formulário será comumente usado. Permitir um bloco se for alinhado é quase a mesma coisa, exceto que também é explícito sobre quais são os valores de retorno
• Ele não promove o uso de retornos nomeados ou empacotamento baseado defer pouco claro. Ambos aumentam a barreira para erros de encapsulamento e o primeiro pode exigir alterações godoc
• Não há necessidade de discussão sobre quando usar try versus usar o tratamento de erros tradicional
• Não exclui fazer try ou qualquer outra coisa no futuro. A mudança pode ser positiva mesmo que try seja aceito
• Nenhuma interação negativa com a biblioteca $# testing 7$#$ ou funções main . Na verdade, se a proposta permitir qualquer instrução de linha única em vez de apenas retornos, ela poderá reduzir o uso de bibliotecas baseadas em asserção. Considerar

value, err := something()
if err != nil { t.Fatal(err) }

• Nenhuma interação negativa com a verificação de erros específicos. Considerar

n, err := src.Read(buf)
if err == io.EOF { return nil }
else if err != nil { return err }

Em resumo, esta proposta tem um custo pequeno, pode ser projetada para ser opt-in, não impede nenhuma alteração adicional, pois é apenas estilística e reduz a dor de ler o código de tratamento de erros detalhado, mantendo tudo explícito. Acho que deve ser pelo menos considerado como um primeiro passo antes de ir all-in try .

De https://github.com/golang/go/issues/32437#issuecomment -498941435

Com tentativa

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        try(dbfile.RunMigrations(db, dbMigrations))
        t := &Thing{
                thingy:  thingy,
                scanner: try(newScanner(thingy, db, client)),
        }
        t.initOtherThing()
        return t, nil
}

Com isso

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        err := dbfile.RunMigrations(db, dbMigrations))
        if err != nil { return nil, fmt.Errorf("running migrations: %v", err) }

        t := &Thing{thingy: thingy}
        t.scanner, err = newScanner(thingy, db, client)
        if err != nil { return nil, fmt.Errorf("creating scanner: %v", err) }

        t.initOtherThing()
        return t, nil
}

É competitivo no uso do espaço e ainda permite adicionar contexto aos erros.

De https://github.com/golang/go/issues/32437#issuecomment -499007288

Com tentativa

func (c *Config) Build() error {
    pkgPath := try(c.load())
    b := bytes.NewBuffer(nil)
    try(emplates.ExecuteTemplate(b, "main", c))
    buf := try(format.Source(b.Bytes()))
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    try(ioutil.WriteFile(target, buf, 0644))
    // ...
}

Com isso

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil { return nil, errors.WithMessage(err, "load config dir") }

    b := bytes.NewBuffer(nil)
    err = templates.ExecuteTemplate(b, "main", c)
    if err != nil { return nil, errors.WithMessage(err, "execute main template") }

    buf, err := format.Source(b.Bytes())
    if err != nil { return nil, errors.WithMessage(err, "format main template") }

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    err = ioutil.WriteFile(target, buf, 0644)
    if err != nil { return nil, errors.WithMessagef(err, "write file %s", target) }
    // ...
}

O comentário original usou um hipotético tryf para anexar a formatação, que foi removida. Não está claro a melhor maneira de adicionar todos os contextos distintos e talvez try nem seja aplicável.

@cpuguy83
Para mim, é mais legível com try . Neste exemplo eu li "abra um arquivo, leia todos os bytes, envie dados". Com o tratamento de erros regular, eu leria "abra um arquivo, verifique se houve um erro, o tratamento de erros faz isso, depois leia todos os bytes, agora verifique se algo aconteceu ..." Eu sei que você pode verificar o err != nil s, mas para mim try é apenas mais fácil porque quando o vejo, reconheço o comportamento imediatamente: retorna se err != nil. Se você tem um ramo eu tenho que ver o que ele faz. Poderia fazer qualquer coisa.

Eu também argumentaria que um manipulador de erro de adiamento aqui não seria bom, exceto para apenas envolver o erro com uma nova mensagem

Tenho certeza de que há outras coisas que você pode fazer no adiamento, mas independentemente disso, try é para o caso geral simples de qualquer maneira. Sempre que você quiser fazer algo mais, sempre há um bom e velho tratamento de erros do Go. Isso não vai embora.

@zeebo Sim, eu gosto disso.
O artigo do @kungfusheep usou uma verificação de erro de uma linha como essa e eu saí para experimentá-lo. Então, assim que salvei, gofmt o expandiu em três linhas, o que foi triste. Muitas funções no stdlib são definidas em uma linha assim, então me surpreendeu que o gofmt expandisse isso.

@qrpnxz

Acontece que eu leio muito código go. Uma das melhores coisas sobre a linguagem é a facilidade que vem da maioria dos códigos seguindo um estilo particular (obrigado gofmt).
Eu não quero ler um monte de código envolto em try(f()) .
Isso significa que haverá uma divergência no estilo/prática de código, ou linters como "oh, você deveria ter usado try() aqui" (o que novamente eu nem gosto, que é o ponto de eu e outros comentarem nesta proposta).

Não é objetivamente melhor que if err != nil { return err } , apenas menos para digitar.

Uma última coisa:

Se você ler a proposta, verá que não há nada que o impeça de

Podemos, por favor, abster-se de tal linguagem? Claro que li a proposta. Acontece que eu li ontem à noite e então comentei esta manhã depois de pensar sobre isso e não expliquei a minúcia do que eu pretendia.
Este é um tom incrivelmente adversário.

@cpuguy83
Meu cara ruim de CPU. Eu não quis dizer isso dessa forma.

E acho que você precisa apontar que o código que usa try será bem diferente do código que não usa, então posso imaginar que isso afetaria a experiência de analisar esse código, mas não posso concordar totalmente que diferentes significa pior neste caso, embora eu entenda que você pessoalmente não gosta, assim como eu pessoalmente gosto. Muitas coisas em Go são assim. Quanto ao que os linters dizem para você fazer é outra questão, eu acho.

Claro que não é objetivamente melhor. Eu estava expressando que era mais legível assim para mim . Eu cuidadosamente escrevi isso.

Mais uma vez, desculpe por soar assim. Embora este seja um argumento, eu não quis antagonizar você.

https://github.com/golang/go/issues/32437#issuecomment -498908380

Ninguém vai fazer você usar tentar.

Ignorando a ligeireza, acho que é uma maneira bastante ondulada de descartar uma crítica de design.

Claro, eu não tenho que usá-lo. Mas qualquer pessoa com quem eu escrevo código pode usá-lo e me forçar a tentar decifrar try(try(try(to()).parse().this)).easily()) . É como dizer

Ninguém vai fazer você usar a interface vazia{}.

De qualquer forma, Go é bastante rigoroso com a simplicidade: gofmt faz com que todo o código tenha a mesma aparência. O caminho feliz continua à esquerda e tudo o que pode ser caro ou surpreendente fica explícito . try como é proposto é um giro de 180 graus a partir disso. Simplicidade != conciso.

No mínimo try deve ser uma palavra-chave com lvalues.

Não é _objetivamente_ melhor que if err != nil { return err } , apenas menos para digitar.

Há uma diferença objetiva entre os dois: try(Foo()) é uma expressão. Para alguns, essa diferença é uma desvantagem (a crítica try(strconv.Atoi(x))+try(strconv.Atoi(y)) ). Para outros, essa diferença é uma vantagem pelo mesmo motivo. Ainda não objetivamente melhor ou pior - mas também não acho que a diferença deva ser varrida para debaixo do tapete e alegar que é "apenas menos digitar" não faz justiça à proposta.

@elagergren-spideroak difícil dizer que try é chato de se ver em uma respiração e depois dizer que não é explícito na próxima. Você tem que escolher um.

é comum ver argumentos de função sendo colocados primeiro em variáveis ​​temporárias. Tenho certeza que seria mais comum ver

this := try(to()).parse().this
that := try(this.easily())

do que o seu exemplo.

try não fazer nada é o caminho feliz, então isso parece o esperado. No caminho infeliz tudo o que faz é retornar. Vendo que há um try é suficiente para reunir essa informação. Também não há nada caro em retornar de uma função, então a partir dessa descrição eu não acho que try esteja fazendo um 180

@josharian Em relação ao seu comentário em https://github.com/golang/go/issues/32437#issuecomment -498941854 , não acho que haja um erro de avaliação antecipada aqui.

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

O valor não modificado de err é passado para HandleErrorf e um ponteiro para err é passado. Verificamos se err é nil (usando o ponteiro). Caso contrário, formatamos a string, usando o valor não modificado de err . Em seguida, definimos err para o valor de erro formatado, usando o ponteiro.

@Merovius A proposta realmente é apenas uma macro de açúcar de sintaxe, então acabará sendo sobre o que as pessoas acham que parece mais legal ou causará menos problemas. Se você acha que não, por favor me explique. É por isso que sou a favor, pessoalmente. É uma boa adição sem adicionar palavras-chave da minha perspectiva.

@ianlancetaylor , acho que @josharian está correto: o valor “não modificado” de err é o valor no momento em que o defer é colocado na pilha, não o valor (presumivelmente pretendido) de err definido por try antes de retornar.

O outro problema que tenho com try é que torna muito mais fácil para as pessoas despejarem mais lógica em uma única linha. Este é o meu maior problema com a maioria das outras linguagens, é que elas tornam muito fácil colocar 5 expressões em uma única linha, e eu não quero isso de lado.

this := try(to()).parse().this
that := try(this.easily())

^^ mesmo isso é absolutamente horrível. A primeira linha, eu tenho que pular para frente e para trás fazendo a correspondência de parênteses na minha cabeça. Mesmo a segunda linha, que na verdade é bem simples... é muito difícil de ler.
Funções aninhadas são difíceis de ler.

parser, err := to()
if err != nil {
    return err
}
this := parser.parse().this
that, err := this.easily()
if err != nil {
    return err
}

^^ Isso é muito mais fácil e melhor IMO. É super simples e claro. sim, são muito mais linhas de código, não me importo. É muito óbvio.

@bcmills @josharian Ah, claro, obrigado. Então teria que ser

defer func() { fmt.HandleErrorf(&err, “foobar: %v”, err) }()

Não tão legal. Talvez fmt.HandleErrorf deva passar implicitamente o valor do erro como o último argumento, afinal.

Esta questão recebeu muitos comentários muito rapidamente, e muitos deles me parecem estar repetindo comentários que já foram feitos. Claro, sinta-se à vontade para comentar, mas gostaria de sugerir gentilmente que, se você quiser reafirmar um ponto que já foi feito, faça isso usando os emojis do GitHub, em vez de repetir o ponto. Obrigado.

@ianlancetaylor se fmt.HandleErrorf enviar err como o primeiro argumento após o formato, a implementação será melhor e o usuário poderá referenciá-lo por %[1]v sempre.

@natefinch Concordo absolutamente.

Gostaria de saber se uma abordagem de estilo ferrugem seria mais palatável?
Observe que esta não é uma proposta apenas pensando nisso ...

this := to()?.parse().this
that := this.easily()?

No final eu acho que isso é mais legal, mas (poderia usar um ! ou qualquer outra coisa também...), mas ainda não corrige bem o problema de manipulação de erros.

é claro que ferrugem também tem try() mais ou menos assim, mas... o outro estilo ferrugem.

Não é _objetivamente_ melhor que if err != nil { return err } , apenas menos para digitar.

Há uma diferença objetiva entre os dois: try(Foo()) é uma expressão. Para alguns, essa diferença é uma desvantagem (a crítica try(strconv.Atoi(x))+try(strconv.Atoi(y)) ). Para outros, essa diferença é uma vantagem pelo mesmo motivo. Ainda não objetivamente melhor ou pior - mas também não acho que a diferença deva ser varrida para debaixo do tapete e alegar que é "apenas menos digitar" não faz justiça à proposta.

Esta é uma das maiores razões pelas quais eu gosto desta sintaxe; ele me permite usar uma função de retorno de erro como parte de uma expressão maior sem precisar nomear todos os resultados intermediários. Em algumas situações, nomeá-los é fácil, mas em outras não há um nome particularmente significativo ou não redundante para dar a eles, caso em que eu prefiro não dar um nome a eles.

@MrTravisB

Exatamente meu ponto. Esta proposta está tentando resolver um caso de uso singular em vez de fornecer uma ferramenta para resolver o problema maior de tratamento de erros. Eu acho que a questão fundamental é exatamente o que você apontou.

O que especificamente eu disse que é exatamente o seu ponto? Parece-me que você entendeu mal meu ponto de vista se acha que concordamos.

Na minha opinião e experiência, este caso de uso é uma pequena minoria e não garante sintaxe abreviada.

Na fonte Go, existem milhares de casos que podem ser tratados por try imediatamente, mesmo que não haja como adicionar contexto aos erros. Se menor, ainda é uma causa comum de reclamação.

Além disso, a abordagem de usar defer para lidar com erros tem problemas, pois pressupõe que você deseja lidar com todos os erros possíveis da mesma forma. instruções defer não podem ser canceladas.

Da mesma forma, a abordagem de usar + para lidar com aritmética pressupõe que você não quer subtrair, então você não quer se não quiser. A questão interessante é se o contexto de erro em todo o bloco representa pelo menos um padrão comum.

E se eu quiser um tratamento de erros diferente para erros que podem ser retornados de foo() vs foo2()

Novamente, então você não usa try . Então você não ganha nada com try , mas também não perde nada.

@cpuguy83

Gostaria de saber se uma abordagem de estilo ferrugem seria mais palatável?

A proposta apresenta um argumento contra isso.

Neste ponto, acho que ter try{}catch{} é mais legível :upside_down_face:

1. Usar importações nomeadas para contornar casos de canto defer não é apenas horrível para coisas como godoc, mas o mais importante é muito propenso a erros. Eu não me importo que eu possa embrulhar a coisa toda com mais func() para contornar o problema, é apenas mais coisas que preciso ter em mente, acho que incentiva uma "má prática".

2. Ninguém vai fazer você usar tentar.

   Isso não significa que seja uma boa solução, estou afirmando que a ideia atual tem uma falha no design e estou pedindo que ela seja abordada de uma maneira menos propensa a erros.

3. Acho que exemplos como try(try(try(to()).parse().this)).easily()) não são realistas, isso já poderia ser feito com outras funções e acho que seria justo para quem está revisando o código pedir para que ele seja dividido.

4. E se eu tiver 3 lugares que podem apresentar erros e eu quiser envolver cada lugar separadamente? try() torna isso muito difícil, na verdade try() já está desencorajando erros de empacotamento dada a dificuldade disso, mas aqui está um exemplo do que quero dizer:

   func before() error {
     x, err := foo()
     if err != nil {
       wrap(err, "error on foo")
     }
     y, err := bar(x)
     if err != nil {
       wrapf(err, "error on bar with x=%v", x)
     }
     fmt.Println(y)
     return nil
   }
   
   func after() (err error) {
     defer fmt.HandleErrorf(&err, "something failed but I don't know where: %v", err)
     x := try(foo())
     y := try(bar(x))
     fmt.Println(y)
     return nil
   }
   

5. Novamente, então você não usa try . Então você não ganha nada com try , mas também não perde nada.

   Digamos que seja uma boa prática envolver erros com contexto útil, try() seria considerado uma prática ruim porque não está adicionando nenhum contexto. Isso significa que try() é um recurso que ninguém quer usar e se tornou um recurso que é usado tão raramente que pode não ter existido.

   Em vez de apenas dizer "bem, se você não gosta, não use e cale a boca" (é assim que se lê), acho que seria melhor tentar abordar o que muitos de uso estão considerando uma falha no projeto. Podemos discutir, em vez disso, o que poderia ser modificado a partir do design proposto para que nossa preocupação seja tratada de uma maneira melhor?

@boomlinde O ponto em que concordamos é que esta proposta está tentando resolver um caso de uso menor e o fato de que "se você não precisa, não use" é o principal argumento para avançar nesse ponto. Como @elagergren-spideroak afirmou, esse argumento não funciona porque, mesmo que eu não queira usá-lo, outros o farão, o que me obriga a usá-lo. Pela lógica do seu argumento, Go também deve ter uma declaração ternária. E se você não gosta de declarações ternárias, não as use.

Isenção de responsabilidade - eu acho que Go deveria ter uma declaração ternária, mas dado que a abordagem de Go para recursos de linguagem é não introduzir recursos que possam tornar o código mais difícil de ler do que não deveria.

Outra coisa me ocorre: estou vendo muitas críticas baseadas na ideia de que ter try pode encorajar os desenvolvedores a lidar com erros de forma descuidada. Mas, na minha opinião, isso é mais verdadeiro para a linguagem atual; o clichê de tratamento de erros é irritante o suficiente para encorajar a pessoa a engolir ou ignorar alguns erros para evitá-lo. Por exemplo, eu escrevi coisas assim algumas vezes:

func exists(filename string) bool {
  _, err := os.Stat(filename)
  return err == nil
}

para poder escrever if exists(...) { ... } , mesmo que este código ignore silenciosamente alguns possíveis erros. Se eu tivesse try , provavelmente não me incomodaria em fazer isso e apenas devolveria (bool, error) .

Sendo caótico aqui, vou lançar a ideia de adicionar uma segunda função interna chamada catch que receberá uma função que recebe um erro e retorna um erro sobrescrito, se um catch subsequente é chamado, ele substituirá o manipulador. por exemplo:

func catch(handler func(err error) error) {
  // .. impl ..
}

Agora, essa função interna também será uma função semelhante a uma macro que lidaria com o próximo erro a ser retornado por try assim:

func wrapf(format string, ...values interface{}) func(err error) error {
  // user defined
  return func(err error) error {
    return fmt.Errorf(format + ": %v", ...append(values, err))
  }
}
func sample() {
  catch(wrapf("something failed in foo"))
  try(foo()) // "something failed in foo: <error>"
  x := try(foo2()) // "something failed in foo: <error>"
  // Subsequent calls for catch overwrite the handler
  catch(wrapf("something failed in bar with x=%v", x))
  try(bar(x)) // "something failed in bar with x=-1: <error>"
}

Isso é bom porque eu posso encapsular erros sem defer que podem ser propensos a erros, a menos que usemos valores de retorno nomeados ou envolva com outra função, também é bom porque defer adicionaria o mesmo manipulador de erros para todos os erros, mesmo que eu queira lidar com 2 deles de maneira diferente. Você também pode usá-lo como achar melhor, por exemplo:

func foo(a, b string) (int64, error) {
  return try(strconv.Atoi(a)) + try(strconv.Atoi(b))
}
func withContext(a, b string) (int64, error) {
  catch(func (err error) error {
    return fmt.Errorf("can't parse a: %s, b: %s, err: %v", a, b, err)
  })
  return try(strconv.Atoi(a)) + try(strconv.Atoi(b))
}
func moreExplicitContext(a, b string) (int64, error) {
  catch(func (err error) error {
    return fmt.Errorf("can't parse a: %s, err: %v", a, err)
  })
  x := try(strconv.Atoi(a))
  catch(func (err error) error {
    return fmt.Errorf("can't parse b: %s, err: %v", b, err)
  })
  y := try(strconv.Atoi(b))
  return x + y
}
func withHelperWrapf(a, b string) (int64, error) {
  catch(wrapf("can't parse a: %s", a))
  x := try(strconv.Atoi(a))
  catch(wrapf("can't parse b: %s", b))
  y := try(strconv.Atoi(b))
  return x + y
}
func before(a, b string) (int64, error) {
  x, err := strconv.Atoi(a)
  if err != nil {
    return 0,  fmt.Errorf("can't parse a: %s, err: %v", a, err)
  }
  y, err := strconv.Atoi(b)
  if err != nil {
    return 0,  fmt.Errorf("can't parse b: %s, err: %v", b, err)
  }
  return x + y
}

E ainda no clima caótico (para te ajudar a ter empatia) Se você não gosta catch , não precisa usar.

Agora... eu realmente não quero dizer a última frase, mas parece que não é útil para a discussão, IMO muito agressivo.
Ainda assim, se formos por esse caminho, acho que podemos ter try{}catch(error err){} em vez disso :stuck_out_tongue:

Veja também #27519 - o modelo de erro #id/catch

Ninguém vai fazer você usar tentar.

Ignorando a ligeireza, acho que é uma maneira bastante ondulada de descartar uma crítica de design.

Desculpe, glib não era minha intenção.

O que estou tentando dizer é que try não se destina a ser uma solução 100%. Existem vários paradigmas de tratamento de erros que não são bem tratados por try . Por exemplo, se você precisar adicionar contexto dependente de callsite ao erro. Você sempre pode voltar a usar if err != nil { para lidar com esses casos mais complicados.

É certamente um argumento válido que try não pode lidar com X, para várias instâncias de X. Mas muitas vezes lidar com o caso X significa tornar o mecanismo mais complicado. Há uma compensação aqui, lidar com X por um lado, mas complicando o mecanismo para todo o resto. O que fazemos depende de quão comum é o X e quanta complicação seria necessária para lidar com o X.

Então, por "Ninguém vai fazer você usar tentar", quero dizer que acho que o exemplo em questão está nos 10%, não nos 90%. Essa afirmação certamente está em debate, e fico feliz em ouvir contra-argumentos. Mas eventualmente teremos que traçar a linha em algum lugar e dizer "sim, try não vai lidar com esse caso. Você terá que usar o tratamento de erros de estilo antigo. Desculpe.".

Não é que "try não pode lidar com este caso específico de tratamento de erros" que é o problema, é "try incentiva você a não encapsular seus erros". A idéia check-handle forçou você a escrever uma declaração de retorno, então escrever um empacotamento de erro era bem trivial.

Sob esta proposta, você precisa usar um retorno nomeado com defer , o que não é intuitivo e parece muito hacky.

A idéia check-handle forçou você a escrever uma declaração de retorno, então escrever um empacotamento de erro era bem trivial.

Isso não é verdade - no rascunho do design, toda função que retorna um erro tem um manipulador padrão que apenas retorna o erro.

Com base no ponto travesso do @Goodwine , você realmente não precisa de funções separadas como HandleErrorf se tiver uma única função de ponte como

func handler(err *error, handle func(error) error) {
  // nil handle is treated as the identity
  if *err != nil && handle != nil {
    *err = handle(*err)
  }
}

que você usaria como

defer handler(&err, func(err error) error {
  if errors.Is(err, io.EOF) {
    return nil
  }
  return fmt.Errorf("oops: %w", err)
})

Você poderia fazer handler si mesmo uma semi-mágica como try .

Se for mágico, pode aceitar seu primeiro argumento implicitamente - permitindo que ele seja usado mesmo em funções que não nomeiam seu retorno error , eliminando um dos aspectos menos afortunados da proposta atual e tornando-a menos exigente e propenso a erros de decoração. Claro, isso não reduz muito o exemplo anterior:

defer handler(func(err error) error {
  if errors.Is(err, io.EOF) {
    return nil
  }
  return fmt.Errorf("oops: %w", err)
})

Se fosse mágico dessa maneira, teria que ser um erro de tempo de compilação se fosse usado em qualquer lugar, exceto como argumento para defer . Você poderia dar um passo adiante e fazê-lo adiar implicitamente, mas defer handler lê muito bem.

Como ele usa defer , ele pode chamar sua função handle sempre que houver um erro não nulo sendo retornado, tornando-o útil mesmo sem try pois você pode adicionar um

defer handler(wrapErrWithPackageName)

no topo para fmt.Errorf("mypkg: %w", err) tudo.

Isso lhe dá muito da proposta check / handle mais antiga, mas funciona com adiar naturalmente (e explicitamente) enquanto se livra da necessidade, na maioria dos casos, de nomear explicitamente um err retorno. Como try é uma macro relativamente simples que (eu imagino) poderia ser implementada inteiramente no front-end.

Isso não é verdade - no rascunho do design, toda função que retorna um erro tem um manipulador padrão que apenas retorna o erro.

Meu mal, você está certo.

Quero dizer que acho que o exemplo em questão está nos 10%, não nos 90%. Essa afirmação certamente está em debate, e fico feliz em ouvir contra-argumentos. Mas, eventualmente, teremos que traçar a linha em algum lugar e dizer "sim, o try não resolverá esse caso. Você terá que usar o tratamento de erros de estilo antigo. Desculpe.".

Concordo, minha opinião é que esta linha deve ser traçada ao verificar EOF ou similar, não no empacotamento. Mas talvez se os erros tivessem mais contexto, isso não seria mais um problema.

Poderia try() auto-empacotar erros com contexto útil para depuração? Por exemplo, se xerrors se tornar errors , os erros devem ter algo parecido com um rastreamento de pilha que try() poderia adicionar, não? Se sim, talvez seja o suficiente 🤔

Se os objetivos forem (lendo https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md):

• eliminar o clichê
• alterações mínimas de idioma
• cobrindo "cenários mais comuns"
• adicionando muito pouca complexidade à linguagem

Eu aceitaria a sugestão de dar um ângulo e permitir a migração de código de "pequenos passos" para todos os bilhões de linhas de código por aí.

em vez do sugerido:

func printSum(a, b string) error {
        defer fmt.HandleErrorf(&err, "sum %s %s: %v", a,b, err) 
        x := try(strconv.Atoi(a))
        y := try(strconv.Atoi(b))
        fmt.Println("result:", x + y)
        return nil
}

Nós podemos:

func printSum(a, b string) error {
        var err ErrHandler{HandleFunc : twoStringsErr("printSum",a,b)} 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        return nil
}

O que ganharíamos?
twoStringsErr pode ser embutido em printSum, ou um manipulador geral que sabe como capturar erros (neste caso com 2 parâmetros de string) - então, se eu tiver as mesmas assinaturas de função repetidas usadas em muitas das minhas funções, não preciso reescrever o manipulador cada Tempo
da mesma maneira, posso ter o tipo ErrHandler estendido da maneira:

type ioErrHandler ErrHandler
func (i ErrHandler) Handle() ...{

}

ou

type parseErrHandler ErrHandler
func (p parseErrHandler) Handle() ...{

}

ou

type str2IntErrHandler ErrHandler
func (s str2IntErrHandler) Handle() ...{

}

e use isso em todo o meu código:

func printSum(a, b string) error {
        var pErr str2IntErrHandler 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        return nil
}

Portanto, a necessidade real seria desenvolver um gatilho quando err.Error for definido como não nulo
Usando este método, podemos também:

func (s str2IntErrHandler) Handle() bool{
   **return false**
}

O que diria à função de chamada para continuar em vez de retornar

E use diferentes manipuladores de erros na mesma função:

func printSum(a, b string) error {
        var pErr str2IntErrHandler 
        var oErr overflowError 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        totalAsByte,oErr := sumBytes(x,y)
        sunAsByte,oErr := subtractBytes(x,y)
        return nil
}

etc.

Repassando as metas novamente

• eliminar o clichê - feito
• alterações mínimas de idioma - feito
• cobrindo "cenários mais comuns" - mais do que o IMO sugerido
• adicionando muito pouca complexidade à linguagem - sone
  Além disso - migração de código mais fácil de

x, err := strconv.Atoi(a)

para

x, err.Error := strconv.Atoi(a)

e na verdade - melhor legibilidade (IMO, novamente)

@guybrand você é o mais recente adepto desse tema recorrente (que eu gosto).

Veja https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

@guybrand Essa parece ser uma proposta totalmente diferente; Acho que você deveria arquivá-lo como seu próprio problema para que este possa se concentrar em discutir a proposta de @griesemer .

@natefinch concordo. Acho que isso é mais voltado para melhorar a experiência ao escrever Go em vez de otimizar para leitura. Gostaria de saber se macros ou trechos de IDE poderiam resolver o problema sem que isso se tornasse um recurso da linguagem.

@Bom vinho

Digamos que seja uma boa prática envolver erros com contexto útil, try() seria considerado uma prática ruim porque não está adicionando nenhum contexto. Isso significa que try() é um recurso que ninguém quer usar e se torna um recurso que é usado tão raramente que pode não ter existido.

Conforme observado na proposta (e mostrado por exemplo), try não impede fundamentalmente que você adicione contexto. Eu diria que do jeito que é proposto, adicionar contexto aos erros é totalmente ortogonal a ele. Isso é abordado especificamente no FAQ da proposta.

Eu reconheço que try não será útil se dentro de uma única função houver uma infinidade de contextos diferentes que você deseja adicionar a erros diferentes de chamadas de função. No entanto, também acredito que algo na veia geral de HandleErrorf cobre uma grande área de uso porque apenas adicionar contexto de toda a função aos erros não é incomum.

Em vez de apenas dizer "bem, se você não gosta, não use e cale a boca" (é assim que se lê), acho que seria melhor tentar abordar o que muitos de uso estão considerando uma falha no projeto.

Se é assim que se lê, peço desculpas. Meu ponto não é que você deve fingir que não existe se você não gosta. É que é óbvio que há casos em que try seria inútil e que você não deveria usá-lo em tais casos, o que para esta proposta eu acredito que atinge um bom equilíbrio entre KISS e utilidade geral. Eu não acho que eu estava claro sobre esse ponto.

Obrigado a todos pelo feedback prolífico até agora; isso é muito informativo.
Aqui está minha tentativa de um resumo inicial, para ter uma ideia melhor do feedback. Peço desculpas antecipadamente por qualquer pessoa que eu tenha perdido ou deturpado; Espero que eu tenha entendido a essência geral da coisa certa.

0) Do lado positivo, @rasky , @adg , @eandre , @dpinela e outros expressaram explicitamente felicidade pela simplificação de código que try fornece.

1) A preocupação mais importante parece ser que try não encoraja um bom estilo de tratamento de erros, mas sim promove a "saída rápida". ( @agnivade , @peterbourgon , @politician , @a8m , @eandre , @prologic , @kungfusheep , @cpuguy e outros expressaram sua preocupação com isso.)

2) Muitas pessoas não gostam da ideia de um built-in, ou da sintaxe de função que vem com ele porque esconde um return . Seria melhor usar uma palavra-chave. ( @sheerun , @Redundancy , @dolmen , @komuw , @RobertGrantEllis , @elagergren-spideroak). try também pode ser facilmente ignorado (@peterbourgon), especialmente porque pode aparecer em expressões que podem ser aninhadas arbitrariamente. @natefinch está preocupado que try torna "muito fácil despejar muito em uma linha", algo que geralmente tentamos evitar em Go. Além disso, o suporte do IDE para enfatizar try pode não ser suficiente (@dominikh); try precisa "ficar sozinho".

3) Para alguns, o status quo de declarações explícitas if não é um problema, eles estão felizes com isso ( @bitfield , @marwan-at-work, @natefinch). É melhor ter apenas uma maneira de fazer as coisas (@gbbr); e as instruções if explícitas são melhores que as return implícitas ( @DavexPro , @hmage , @prologic , @natefinch).
Na mesma linha, @mattn está preocupado com a "vinculação implícita" do resultado do erro para try - a conexão não é explicitamente visível no código.

4) Usar try dificultará a depuração do código; por exemplo, pode ser necessário reescrever uma expressão try volta em uma instrução if apenas para que as instruções de depuração possam ser inseridas ( @deanveloper , @typeless , @networkimprov , outros).

5) Há alguma preocupação com o uso de retornos nomeados ( @buchanae , @adg).

Várias pessoas deram sugestões para melhorar ou modificar a proposta:

6) Alguns adotaram a ideia de um manipulador de erros opcional (@beoran) ou string de formato fornecida a try ( @unexge , @a8m , @eandre , @gotwarlost) para incentivar um bom tratamento de erros.

7) @pierrec sugeriu que gofmt poderia formatar expressões try adequadamente para torná-las mais visíveis.
Alternativamente, pode-se tornar o código existente mais compacto, permitindo que gofmt formate instruções if verificando erros em uma linha (@zeebo).

8) @marwan-at-work argumenta que try simplesmente muda o tratamento de erros de instruções $# if 9$#$ para expressões try . Em vez disso, se quisermos realmente resolver o problema, Go deve "possuir" o tratamento de erros, tornando-o verdadeiramente implícito. O objetivo deve ser tornar o tratamento de erros (adequado) mais simples e os desenvolvedores mais produtivos (@cpuguy).

9) Finalmente, algumas pessoas não gostam do nome try ( @beoran , @HiImJC , @dolmen) ou preferem um símbolo como ? ( @twisted1919 , @leaxoy , outros) .

Alguns comentários sobre este feedback (numerados de acordo):

0) Obrigado pelo feedback positivo! :-)

1) Seria bom aprender mais sobre essa preocupação. O estilo de codificação atual usando instruções if para testar erros é o mais explícito possível. É muito fácil adicionar informações adicionais a um erro, individualmente (para cada if ). Muitas vezes faz sentido tratar todos os erros detectados em uma função de forma uniforme, o que pode ser feito com um defer - isso já é possível agora. É o fato de já termos todas as ferramentas para um bom tratamento de erros na linguagem, e o problema de uma construção de manipulador não ser ortogonal a defer , que nos levou a deixar de lado um novo mecanismo apenas para aumentar erros .

2) É claro que existe a possibilidade de usar uma palavra-chave ou sintaxe especial em vez de uma built-in. Uma nova palavra-chave não será compatível com versões anteriores. Um novo operador pode, mas parece ainda menos visível. A proposta detalhada discute detalhadamente os vários prós e contras. Mas talvez estejamos julgando mal isso.

3) A razão para esta proposta é que o tratamento de erros (especificamente o código padrão associado) foi mencionado como um problema significativo em Go (junto à falta de genéricos) pela comunidade Go. Esta proposta aborda diretamente a preocupação do clichê. Ele não faz mais do que resolver o caso mais básico porque qualquer caso mais complexo é melhor tratado com o que já temos. Portanto, embora um bom número de pessoas esteja satisfeito com o status quo, há um contingente (provavelmente) igualmente grande de pessoas que adoraria uma abordagem mais simplificada, como try , sabendo que isso é "apenas" açúcar sintático.

4) O ponto de depuração é uma preocupação válida. Se houver necessidade de adicionar código entre detectar um erro e um return , ter que reescrever uma expressão try em uma instrução if pode ser irritante.

5) Valores de retorno nomeados: O documento detalhado discute isso detalhadamente. Se esta é a principal preocupação sobre esta proposta, então estamos em um bom lugar, eu acho.

6) Argumento de manipulador opcional para try : O documento detalhado também discute isso. Consulte a seção sobre iterações de design.

7) Usar gofmt para formatar expressões try forma que fiquem mais visíveis certamente seria uma opção. Mas isso tiraria alguns dos benefícios de try quando usado em uma expressão.

8) Consideramos olhar para o problema do ponto de vista do tratamento de erros ( handle ) em vez do ponto de vista do teste de erros ( try ). Especificamente, consideramos brevemente apenas introduzir a noção de um manipulador de erros (semelhante ao rascunho do projeto original apresentado no Gophercon do ano passado). O pensamento era que se (e somente se) um manipulador for declarado, em atribuições de vários valores onde o último valor é do tipo error , esse valor pode simplesmente ser deixado de lado em uma atribuição. O compilador verificaria implicitamente se não é nulo e, em caso afirmativo, ramificaria para o manipulador. Isso faria o tratamento de erros explícito desaparecer completamente e encorajaria todos a escreverem um handler. Isso parecia uma abordagem extrema porque seria completamente implícito - o fato de que uma verificação acontecesse seria invisível.

9) Posso sugerir que não troquemos de bicicleta o nome neste momento. Uma vez que todas as outras preocupações são resolvidas, é um momento melhor para ajustar o nome.

Isso não quer dizer que as preocupações não sejam válidas - as respostas acima estão simplesmente afirmando nosso pensamento atual. No futuro, seria bom comentar sobre novas preocupações (ou novas evidências em apoio a essas preocupações) - apenas reafirmar o que já foi dito não nos fornece mais informações.

E, finalmente, parece que nem todos que comentam sobre o assunto leram o documento detalhado. Por favor, faça isso antes de comentar para evitar repetir o que já foi dito. Obrigado.

Este não é um comentário sobre a proposta, mas um relatório de erros de digitação. Não foi corrigido desde que a proposta completa foi publicada, então pensei em mencioná-la:

func try(t1 T1, t1 T2, … tn Tn, te error) (T1, T2, … Tn)

deveria estar:

func try(t1 T1, t2 T2, … tn Tn, te error) (T1, T2, … Tn)

Valeria a pena analisar o código Go abertamente disponível para instruções de verificação de erros para tentar descobrir se a maioria das verificações de erros é realmente repetitiva ou se, na maioria dos casos, várias verificações dentro da mesma função adicionam informações contextuais diferentes? A proposta faria muito sentido para o primeiro caso, mas não ajudaria o segundo. No último caso, as pessoas continuarão usando if err != nil ou desistirão de adicionar contexto extra, usarão try() e recorrerão à adição de contexto de erro comum por função que IMO seria prejudicial. Com os próximos recursos de valores de erro, acho que esperamos que as pessoas envolvam erros com mais informações com mais frequência. Provavelmente eu entendi mal a proposta, mas AFAIU, isso ajuda a reduzir o clichê apenas quando todos os erros de uma única função devem ser encapsulados exatamente de uma maneira e não ajuda se uma função lidar com cinco erros que podem precisar ser encapsulados de maneira diferente. Não tenho certeza de quão comuns são esses casos na natureza (bastante comuns na maioria dos meus projetos), mas estou preocupado que try() possa incentivar as pessoas a usar wrappers comuns por função, mesmo quando faria sentido agrupar erros diferentes diferente.

Apenas um comentário rápido com dados de um pequeno conjunto de amostras:

Propomos uma nova função interna chamada try, projetada especificamente para eliminar o clichê se as instruções normalmente associadas ao tratamento de erros em Go

Se este for o problema central que está sendo resolvido por esta proposta, acho que esse "clichê" representa apenas ~ 1,4% do meu código em dezenas de projetos de código aberto disponíveis publicamente, totalizando ~ 60k SLOC.

Curioso se alguém tem estatísticas semelhantes?

Em uma base de código muito maior como o próprio Go, totalizando cerca de 1,6 milhão de SLOC, isso equivale a cerca de 0,5% da base de código com linhas como if err != nil .

Esse é realmente o problema mais impactante para resolver com o Go 2?

Muito obrigado @griesemer por dedicar um tempo para analisar as ideias de todos e fornecer pensamentos explicitamente. Acho que ajuda muito na percepção de que a comunidade está sendo ouvida no processo.

1. @pierrec sugeriu que o gofmt pudesse formatar as expressões try adequadamente para torná-las mais visíveis.
   Alternativamente, pode-se tornar o código existente mais compacto, permitindo que o gofmt formate instruções if verificando erros em uma linha (@zeebo).

1. Usar gofmt para formatar expressões try de forma que fiquem mais visíveis certamente seria uma opção. Mas tiraria alguns dos benefícios de try quando usado em uma expressão.

Estes são pensamentos valiosos sobre exigir gofmt para formatar try , mas estou interessado se houver algum pensamento em particular sobre gofmt permitir a verificação de declaração if o erro seja uma linha. A proposta foi agrupada com formatação de try , mas acho que é uma coisa completamente ortogonal. Obrigado.

@griesemer obrigado pelo trabalho incrível passando por todos os comentários e respondendo a maioria, senão todos os comentários 🎉

Uma coisa que não foi abordada em seu feedback foi a ideia de usar a parte de ferramentas/verificação da linguagem Go para melhorar a experiência de tratamento de erros, em vez de atualizar a sintaxe Go.

Por exemplo, com a chegada do novo LSP ( gopls ), parece um lugar perfeito para analisar a assinatura de uma função e cuidar do clichê de tratamento de erros para o desenvolvedor, com envolvimento e verificação adequados também.

@griesemer Tenho certeza de que isso não foi bem pensado, mas tentei modificar sua sugestão mais perto de algo com o qual me sentiria confortável aqui: https://www.reddit.com/r/golang/comments/bwvyhe /proposal_a_builtin_go_error_check_function_try/eq22bqa?utm_source=share&utm_medium=web2x

@zeebo Seria fácil fazer gofmt formatar if err != nil { return ...., err } em uma única linha. Presumivelmente, seria apenas para esse tipo específico de padrão if , não para todas as instruções if "curtas"?

Na mesma linha, havia preocupações sobre try ser invisível porque está na mesma linha que a lógica de negócios. Temos todas essas opções:

Estilo atual:

a, b, c, ... err := BusinessLogic(...)
if err != nil {
   return ..., err
}

Uma linha if :

a, b, c, ... err := BusinessLogic(...)
if err != nil { return ..., err }

try em uma linha separada (!):

a, b, c, ... err := BusinessLogic(...)
try(err)

try como proposto:

a, b, c := try(BusinessLogic(...))

A primeira e a última linha parecem as mais claras (para mim), especialmente quando se usa para reconhecer try como o que é. Com a última linha, um erro é explicitamente verificado, mas como (geralmente) não é a ação principal, fica um pouco mais em segundo plano.

@marwan-at-work Não tenho certeza do que você está propondo que as ferramentas fazem por você. Você sugere que eles ocultem o tratamento de erros de alguma forma?

@dpinela

@guybrand Essa parece ser uma proposta totalmente diferente; Acho que você deveria arquivá-lo como seu próprio problema para que este possa se concentrar em discutir a proposta de @griesemer .

IMO minha proposta difere apenas na sintaxe, ou seja:

• As metas são semelhantes em conteúdo e prioridade.
• A ideia de capturar cada erro dentro de sua própria linha e, consequentemente (se não for nil), sair da função enquanto passa por uma função de manipulador é semelhante (pseudo asm - é um "jnz" e "call").
• Isso significa que o número de linhas em um corpo de função (sem o defer) e o fluxo seriam exatamente iguais (e, portanto, o AST provavelmente também seria o mesmo)

então a principal diferença é se estamos envolvendo a chamada de função original com try(func()) que sempre analisaria a última var para jnz a chamada ou usaria o valor de retorno real para fazer isso.

Eu sei que parece diferente, mas na verdade muito semelhante em conceito.
Por outro lado - se você fizer a tentativa usual .... pegar em muitas linguagens do tipo c - isso seria uma implementação muito diferente, legibilidade diferente etc.

No entanto, penso seriamente em escrever uma proposta, obrigado pela ideia.

@griesemer

Não tenho certeza do que você está propondo que as ferramentas são para você. Você sugere que eles ocultem o tratamento de erros de alguma forma?

Muito pelo contrário: estou sugerindo que gopls pode opcionalmente escrever o clichê de tratamento de erros para você.

Como você mencionou em seu último comentário:

A razão para esta proposta é que o tratamento de erros (especificamente o código padrão associado) foi mencionado como um problema significativo em Go (junto à falta de genéricos) pela comunidade Go

Portanto, o cerne do problema é que o programador acaba escrevendo muito código clichê. Então a questão é escrever, não ler. Portanto, minha sugestão é: deixe o computador (tooling/gopls) fazer a escrita para o programador analisando a assinatura da função e colocando cláusulas de tratamento de erros apropriadas.

Por exemplo:

// user begins to write this function: 
func openFile(path string) ([]byte, error) {
  file, err := os.Open(path)
  defer file.Close()
  bts, err := ioutil.ReadAll(file)
  return bts, nil
}

Em seguida, o usuário aciona a ferramenta, talvez apenas salvando o arquivo (semelhante a como gofmt/goimports normalmente funcionam) e gopls iria olhar para esta função, analisar sua assinatura de retorno e aumentar o código para ser este:

// user has triggered the tool (by saving the file, or code action)
func openFile(path string) ([]byte, error) {
  file, err := os.Open(path)
  if err != nil {
    return nil, fmt.Errorf("openFile: %w", err)
  }
  defer file.Close()
  bts, err := ioutil.ReadAll(file)
  if err != nil {
    return nil, fmt.Errorf("openFile: %w", err)
  }
  return bts, nil
}

Dessa forma, obtemos o melhor dos dois mundos: obtemos a legibilidade/explicidade do sistema de tratamento de erros atual, e o programador não escreveu nenhum clichê de tratamento de erros. Melhor ainda, o usuário pode ir em frente e modificar os blocos de tratamento de erros mais tarde para ter um comportamento diferente: gopls pode entender que o bloco existe e não o modificaria.

Como a ferramenta saberia que eu pretendia lidar com err mais tarde na função em vez de retornar mais cedo? Embora raro, mas o código que eu escrevi mesmo assim.

Peço desculpas se isso já foi mencionado antes, mas não encontrei nenhuma menção a isso.

try(DoSomething()) lê bem para mim e faz sentido: o código está tentando fazer alguma coisa. try(err) , OTOH, parece um pouco estranho, semanticamente falando: como se tenta um erro? Na minha opinião, pode-se _test_ ou _check_ um erro, mas _tentar_ não parece certo.

Eu percebo que permitir try(err) é importante por razões de consistência: suponho que seria estranho se try(DoSomething()) funcionasse, mas err := DoSomething(); try(err) não. Ainda assim, parece que try(err) parece um pouco estranho na página. Não consigo pensar em nenhuma outra função interna que possa parecer tão estranha tão facilmente.

Não tenho sugestões concretas sobre o assunto, mas mesmo assim quis fazer esta observação.

@griesemer Obrigado. Na verdade, a proposta era apenas para return , mas suspeito que permitir que qualquer instrução seja uma única linha seria bom. Por exemplo, em um teste, pode-se, sem alterações na biblioteca de testes, ter

if err != nil { t.Fatal(err) }

A primeira e a última linha parecem as mais claras (para mim), especialmente quando se está acostumado a reconhecer try como o que é. Com a última linha, um erro é explicitamente verificado, mas como (geralmente) não é a ação principal, fica um pouco mais em segundo plano.

Com a última linha, parte do custo fica oculto. Se você quiser anotar o erro, que acredito que a comunidade disse vocalmente ser a melhor prática desejada e deve ser incentivada, seria necessário alterar a assinatura da função para nomear os argumentos e esperar que um único defer fosse aplicado a cada saída no corpo da função, caso contrário try não tem valor; talvez até negativo devido à sua facilidade.

Não tenho mais nada a acrescentar que acredito que já não tenha sido dito.

Eu não vi como responder a esta pergunta do documento de design. O que faz este código:

func foo() (err error) {
    src := try(getReader())
    if src != nil {
        n, err := src.Read(nil)
        if err == io.EOF {
            return nil
        }
        try(err)
        println(n)
    }
    return nil
}

Meu entendimento é que seria desaçúcar em

func foo() (err error) {
    tsrc, te := getReader()
    if err != nil {
        err = te
        return
    }
    src := tsrc

    if src != nil {
        n, err := src.Read(nil)
        if err == io.EOF {
            return nil
        }

        terr := err
        if terr != nil {
            err = terr
            return
        }

        println(n)
    }
    return nil
}

que falha ao compilar porque err é sombreado durante um retorno nu. Isso não compilaria? Se assim for, isso é uma falha muito sutil e não parece muito improvável de acontecer. Se não, então está acontecendo mais do que um pouco de açúcar.

@marwan-at-work

Como você mencionou em seu último comentário:

A razão para esta proposta é que o tratamento de erros (especificamente o código padrão associado) foi mencionado como um problema significativo em Go (junto à falta de genéricos) pela comunidade Go

Portanto, o cerne do problema é que o programador acaba escrevendo muito código clichê. Então a questão é escrever, não ler.

Acho que na verdade é o contrário - para mim, o maior aborrecimento com o clichê atual de tratamento de erros não é tanto ter que digitá-lo, mas como ele espalha o caminho feliz da função verticalmente pela tela, dificultando a compreensão em uma olhadela. O efeito é particularmente pronunciado em código pesado de E/S, onde geralmente há um bloco de clichê entre cada duas operações. Mesmo uma versão simplista de CopyFile leva ~ 20 linhas, embora realmente execute apenas cinco etapas: código aberto, adiar código fechado, destino aberto, fonte de cópia -> destino, destino fechado.

Outro problema com a sintaxe atual é que, como observei anteriormente, se você tiver uma cadeia de operações, cada uma das quais pode retornar um erro, a sintaxe atual o forçará a dar nomes a todos os resultados intermediários, mesmo que você prefira deixe algum anônimo. Quando isso acontece, também prejudica a legibilidade porque você tem que gastar ciclos cerebrais analisando esses nomes, mesmo que eles não sejam muito informativos.

Eu gosto de try em uma linha separada.
E espero que possa especificar handler func independentemente.

func try(error, optional func(error)error)

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    try(err)

    handle := func(err error) error {
        tx.Rollback()
        return err
    }

    var res int64
    _, err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    try(err, handle)

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    try(err, handle)

    return tx.Commit()
}

@zeebo : Os exemplos que dei são traduções 1:1. O primeiro (tradicional if ) não lidou com o erro, assim como os outros. Se o primeiro tratou do erro, e se este fosse o único lugar em que um erro é verificado em uma função, o primeiro exemplo (usando um if ) pode ser a escolha apropriada de escrever o código. Se houver várias verificações de erros, todas usando o mesmo tratamento de erros (agrupamento), digamos, porque todas adicionam informações sobre a função atual, pode-se usar uma instrução defer para lidar com os erros em um só lugar. Opcionalmente, pode-se reescrever os if 's em try 's (ou deixá-los em paz). Se houver vários erros para verificar, e todos eles tratarem os erros de forma diferente (o que pode ser um sinal de que a preocupação da função é muito ampla e que pode precisar ser dividida), usar if 's é o caminho a percorrer. Sim, há mais de uma maneira de fazer a mesma coisa, e a escolha certa depende do código e também do gosto pessoal. Embora nós nos esforcemos em Go por "uma maneira de fazer uma coisa", é claro que isso já não é o caso, especialmente para construções comuns. Por exemplo, quando uma sequência if - else - if se torna muito longa, às vezes uma sequência switch pode ser mais apropriada. Às vezes, uma declaração de variável var x int expressa a intenção melhor do que x := 0 e assim por diante (embora nem todos estejam felizes com isso).

Em relação à sua pergunta sobre a "reescrita": Não, não haveria erro de compilação. Observe que a reescrita acontece internamente (e pode ser mais eficiente do que o padrão de código sugere), e não há necessidade de o compilador reclamar de um retorno oculto. Em seu exemplo, você declarou uma variável local err em um escopo aninhado. try ainda teria acesso direto à variável de resultado err , é claro. A reescrita pode se parecer mais com isso nos bastidores.

[editado] PS: Uma resposta melhor seria: try não é um retorno nu (mesmo que a reescrita pareça). Afinal, dá-se explicitamente try um argumento que contém (ou é) o erro que é retornado se não for nil . O erro de sombra para retornos nus é um erro na fonte (não na tradução subjacente da fonte. O compilador não precisa do erro.

Se o tipo de retorno final da função abrangente não for do tipo erro, podemos entrar em pânico?

Isso tornará o built-in mais versátil (como satisfazer minha preocupação em # 32219)

@pjebs Isso foi considerado e decidido contra. Por favor, leia o documento de design detalhado (que se refere explicitamente ao seu problema sobre este assunto).

Eu também quero apontar que try() é tratado como expressão, embora funcione como instrução de retorno. Sim, eu sei que try é uma macro integrada, mas a maioria dos usuários usará isso como programação funcional, eu acho.

func doSomething() (error, error, error, error, error) {
   ...
}

try(try(try(try(try(doSomething)))))

O design diz que você explorou usando panic em vez de retornar com o erro.

Destaco uma sutil diferença:

Faça exatamente o que sua proposta atual afirma, exceto remover a restrição de que a função abrangente deve ter um tipo de retorno final do tipo error .

Se não tiver um tipo de retorno final error => panic
Se estiver usando try para declarações de variáveis ​​de nível de pacote => panic (remove a necessidade da convenção MustXXX( ) )

Para testes de unidade, uma modesta mudança de idioma.

@mattn , duvido muito que qualquer número significativo de pessoas escreva código assim.

@pjebs , essa semântica - pânico se não houver resultado de erro na função atual - é exatamente o que o documento de design está discutindo em https://github.com/golang/proposal/blob/master/design/32437-try-builtin. md#discussão.

Além disso, em uma tentativa de tornar try útil não apenas dentro de funções com um resultado de erro, a semântica de try dependia do contexto: se try fosse usado no nível do pacote, ou se fosse chamado dentro de uma função sem um resultado de erro, try entraria em pânico ao encontrar um erro. (Como um aparte, por causa dessa propriedade o built-in foi chamado de deve ao invés de tentar nessa proposta.) Tentar (ou deve) se comportar dessa maneira sensível ao contexto parecia natural e também bastante útil: permitiria a eliminação de muitas funções auxiliares must definidas pelo usuário atualmente usadas em expressões de inicialização de variável de nível de pacote. Também abriria a possibilidade de usar try em testes unitários através do pacote testing.

No entanto, a sensibilidade ao contexto de try foi considerada complicada: por exemplo, o comportamento de uma função contendo chamadas try poderia mudar silenciosamente (de possivelmente entrar em pânico para não entrar em pânico e vice-versa) se um resultado de erro fosse adicionado ou removido da assinatura. Esta parecia uma propriedade muito perigosa. A solução óbvia teria sido dividir a funcionalidade de try em duas funções separadas, must e try (muito semelhante ao que é sugerido pelo problema #31442). Mas isso exigiria duas novas funções internas, com apenas tentar diretamente conectado à necessidade imediata de um melhor suporte ao tratamento de erros.

@pjebs Isso é _exatamente_ o que consideramos em uma proposta anterior (consulte o documento detalhado, seção sobre iterações de design, 4º parágrafo):

Além disso, em uma tentativa de tornar try útil não apenas dentro de funções com um resultado de erro, a semântica de try dependia do contexto: se try fosse usado no nível do pacote, ou se fosse chamado dentro de uma função sem um resultado de erro, try entraria em pânico ao encontrar um erro. (Como um aparte, por causa dessa propriedade o built-in foi chamado de must em vez de tentar nessa proposta.)

O consenso (interno do Go Team) era que seria confuso para try depender do contexto e agir de forma tão diferente. Por exemplo, adicionar um resultado de erro a uma função (ou removê-lo) pode alterar silenciosamente o comportamento da função de entrar em pânico para não entrar em pânico (ou vice-versa).

@griesemer Obrigado pelo esclarecimento sobre a reescrita. Estou feliz que ele irá compilar.

Eu entendo que os exemplos foram traduções que não anotaram os erros. Tentei argumentar que try torna mais difícil fazer uma boa anotação de erros em situações comuns, e que a anotação de erros é muito importante para a comunidade. Uma grande parte dos comentários até agora tem explorado maneiras de adicionar melhor suporte a anotações para try .

Sobre ter que lidar com os erros de forma diferente, discordo que seja um sinal de que a preocupação da função é muito ampla. Estou traduzindo alguns exemplos de código real reivindicado dos comentários e colocando-os em uma lista suspensa na parte inferior do meu comentário original e o exemplo em https://github.com/golang/go/issues/32437#issuecomment - 499007288 acho que demonstra bem um caso comum:

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil { return nil, errors.WithMessage(err, "load config dir") }

    b := bytes.NewBuffer(nil)
    err = templates.ExecuteTemplate(b, "main", c)
    if err != nil { return nil, errors.WithMessage(err, "execute main template") }

    buf, err := format.Source(b.Bytes())
    if err != nil { return nil, errors.WithMessage(err, "format main template") }

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    err = ioutil.WriteFile(target, buf, 0644)
    if err != nil { return nil, errors.WithMessagef(err, "write file %s", target) }
    // ...
}

O objetivo dessa função é executar um modelo em alguns dados em um arquivo. Não acredito que precise ser dividido, e seria lamentável se todos esses erros ganhassem a linha em que foram criados a partir de um adiamento. Isso pode ser bom para os desenvolvedores, mas é muito menos útil para os usuários.

Eu acho que também é um sinal de quão sutis os bugs defer wrap(&err, "message: %v", err) eram e como eles tropeçavam até mesmo programadores Go experientes.

Para resumir meu argumento : acho que a anotação de erro é mais importante do que a verificação de erros baseada em expressões, e podemos obter um pouco de redução de ruído permitindo que a verificação de erros baseada em instruções seja uma linha em vez de três. Obrigado.

@griesemer desculpe, li uma seção diferente que discutia o pânico e não via a discussão dos perigos.

@zeebo Obrigado por este exemplo. Parece que usar uma instrução if é exatamente a escolha certa neste caso. Mas ponto, formatar os if's em one-liners pode simplificar um pouco isso.

Eu gostaria de trazer mais uma vez a idéia de um manipulador como um segundo argumento para try , mas com a adição de que o argumento do manipulador seja _required_, mas nil-able. Isso torna o tratamento do erro o padrão, em vez da exceção. Nos casos em que você realmente deseja passar o erro inalterado, basta fornecer um valor nil ao manipulador e try se comportará exatamente como na proposta original, mas o argumento nil atuará como uma indicação visual de que o erro não está sendo tratado. Será mais fácil detectar durante a revisão do código.

file := try(os.Open("my_file.txt"), nil)

O que deve acontecer se o manipulador for fornecido, mas for nulo? Deve tentar entrar em pânico ou tratá-lo como um manipulador de erros ausente?

Conforme mencionado acima, try se comportará de acordo com a proposta original. Não haveria um manipulador de erros ausente, apenas um nulo.

E se o manipulador for invocado com um erro não nulo e, em seguida, retornar um resultado nulo? Isso significa que o erro foi “cancelado”? Ou a função envolvente deve retornar com um erro nil?

Acredito que a função envolvente retornaria com um erro nil. Seria potencialmente muito confuso se try às vezes pudesse continuar a execução mesmo depois de receber um valor de erro não nulo. Isso permitiria que os manipuladores "cuidassem" do erro em algumas circunstâncias. Esse comportamento pode ser útil em uma função de estilo "obter ou criar", por exemplo.

func getOrCreateObject(obj *object) error {
    defaultObjectHandler := func(err error) error {
        if err == ObjectDoesNotExistErr {
            *obj = object{}
            return nil
        }
        return fmt.Errorf("getting or creating object: %v", err)
    }

    *obj = try(db.getObject(), defaultObjectHandler)
}

Também não ficou claro se permitir um manipulador de erros opcional levaria os programadores a ignorar completamente o tratamento de erros adequado. Também seria fácil fazer o tratamento adequado de erros em todos os lugares, mas perder uma única ocorrência de uma tentativa. E assim por diante.

Acredito que essas duas preocupações são aliviadas ao tornar o manipulador um argumento obrigatório e nulo. Requer que os programadores tomem uma decisão consciente e explícita de que não irão lidar com seu erro.

Como bônus, acho que exigir o manipulador de erros também desencoraja try s profundamente aninhados porque eles são menos breves. Alguns podem ver isso como uma desvantagem, mas acho que é um benefício.

@velovix Eu amo a ideia, mas por que o manipulador de erros precisa ser necessário? Não pode ser nil por padrão? Por que precisamos de uma "pista visual"?

@griesemer E se a ideia @velovix fosse adotada, mas com builtin contendo uma função predefinida que converte err em panic E removemos o requisito de que a função over-arching tenha um valor de retorno de erro?

A idéia é, se a função abrangente não retornar erro, usar try sem manipulador de erros é um erro de tempo de compilação.

O manipulador de erros também pode ser usado para agrupar o erro que será retornado em breve usando várias bibliotecas etc no local do erro, em vez de um defer no topo que modifica um erro retornado nomeado.

@pjebs

por que o manipulador de erros precisa ser necessário? Não pode ser nulo por padrão? Por que precisamos de uma "pista visual"?

Isto é para responder às preocupações que

1. A proposta try como está agora pode desencorajar as pessoas de fornecer contexto para seus erros porque isso não é tão simples.

Ter um manipulador em primeiro lugar facilita o fornecimento de contexto, e ter o manipulador como um argumento obrigatório envia uma mensagem: O caso comum e recomendado é manipular ou contextualizar o erro de alguma forma, não simplesmente passá-lo pela pilha. Está de acordo com a recomendação geral da comunidade Go.

1. Uma preocupação do documento da proposta original. Citei no meu primeiro comentário:

Também não ficou claro se permitir um manipulador de erros opcional levaria os programadores a ignorar completamente o tratamento de erros adequado. Também seria fácil fazer o tratamento adequado de erros em todos os lugares, mas perder uma única ocorrência de uma tentativa. E assim por diante.

Ter que passar um nil explícito torna mais difícil esquecer de lidar com um erro corretamente. Você precisa decidir explicitamente não manipular o erro em vez de fazê-lo implicitamente, deixando de fora um argumento.

Pensando mais sobre o retorno condicional mencionado brevemente em https://github.com/golang/go/issues/32437#issuecomment -498947603.
Parece
return if f, err := os.Open("/my/file/path"); err != nil
seria mais compatível com a aparência do if existente em Go.

Se adicionarmos uma regra para a instrução return if que
quando a última expressão de condição (como err != nil ) não está presente,e a última variável da declaração na instrução return if é do tipo error ,então o valor da última variável será automaticamente comparado com nil como condição implícita.

Então a instrução return if pode ser abreviada em:
return if f, err := os.Open("my/file/path")

O que é muito próximo da relação sinal-ruído que o try fornece.
Se mudarmos return if para try , fica
try f, err := os.Open("my/file/path")
Novamente, torna-se semelhante a outras variações propostas do try neste tópico, pelo menos sintaticamente.
Pessoalmente, ainda prefiro return if sobre try neste caso porque torna os pontos de saída de uma função muito explícitos. Por exemplo, ao depurar, geralmente destaco a palavra-chave return no editor para identificar todos os pontos de saída de uma função grande.

Infelizmente, também não parece ajudar o suficiente com a inconveniência de inserir o log de depuração.
A menos que também permitamos um bloco body para return if , como
Original:

        return if f, err := os.Open("my/path") 

Ao depurar:

-       return if f, err := os.Open("my/path") 
+       return if f, err := os.Open("my/path") {
+               fmt.Printf("DEBUG: os.Open: %s\n", err)
+       }

O significado do bloco de corpo de return if é óbvio, suponho. Ele será executado antes defer e retornará.

Dito isso, não tenho reclamações com a abordagem de tratamento de erros existente no Go.
Estou mais preocupado em como a adição do novo tratamento de erros afetaria a qualidade atual do Go.

@velovix Gostamos bastante da ideia de um try com uma função de manipulador explícita como segundo argumento. Mas havia muitas perguntas que não tinham respostas óbvias, como afirma o documento de design. Você respondeu algumas delas de uma forma que lhe parece razoável. É bem provável (e essa foi a nossa experiência dentro da Go Team) que alguém ache que a resposta correta é bem diferente. Por exemplo, você está afirmando que o argumento do manipulador sempre deve ser fornecido, mas que pode ser nil , para torná-lo explícito, não nos importamos em lidar com o erro. Agora, o que acontece se alguém fornecer um valor de função (não um literal nil ), e esse valor de função (armazenado em uma variável) for nulo? Por analogia com o valor explícito nil , nenhum manuseio é necessário. Mas outros podem argumentar que isso é um bug no código. Ou, alternativamente, pode-se permitir argumentos de manipulador de valor nulo, mas uma função pode manipular erros inconsistentemente em alguns casos e não em outros, e não é necessariamente óbvio no código o que se faz, porque parece que um manipulador está sempre presente . Outro argumento era que é melhor ter uma declaração de nível superior de um manipulador de erros porque isso deixa muito claro que a função trata os erros. Daí o defer . Provavelmente há mais.

Seria bom saber mais sobre essa preocupação. O estilo de codificação atual usando instruções if para testar erros é o mais explícito possível. É muito fácil adicionar informações adicionais a um erro, individualmente (para cada if). Muitas vezes faz sentido tratar todos os erros detectados em uma função de forma uniforme, o que pode ser feito com um adiamento - isso já é possível agora. É o fato de já termos todas as ferramentas para um bom tratamento de erros na linguagem, e o problema de uma construção de manipulador não ser ortogonal para diferir, que nos levou a deixar de lado um novo mecanismo exclusivamente para aumentar erros.

@griesemer - IIUC, você está dizendo que, para contextos de erro dependentes de callsite, a instrução if atual está bem. Considerando que, esta nova função try é útil para os casos em que o tratamento de vários erros em um único local é útil.

Acredito que a preocupação era que, enquanto simplesmente fazer um if err != nil { return err} pode ser bom para alguns casos, geralmente é recomendado decorar o erro antes de retornar. E esta proposta parece abordar o anterior e não faz muito para o último. O que essencialmente significa que as pessoas serão incentivadas a usar o padrão de retorno fácil.

@agnivade Você está correto, esta proposta não faz exatamente nada para ajudar na decoração de erros (mas para recomendar o uso de defer ). Uma razão é que já existem mecanismos de linguagem para isso. Assim que a decoração de erro é necessária, especialmente em uma base de erro individual, a quantidade adicional de texto fonte para o código de decoração torna o if menos oneroso em comparação. São os casos em que nenhuma decoração é necessária, ou onde a decoração é sempre a mesma, onde o clichê se torna um incômodo visível e depois diminui o código importante.

As pessoas já são encorajadas a usar um padrão de retorno fácil, try ou não try , há apenas menos para escrever. Pensando bem, _a única maneira de incentivar a decoração de erros é torná-la obrigatória_, porque não importa qual suporte de idioma esteja disponível, erros de decoração exigirão mais trabalho.

Uma maneira de adoçar o negócio seria permitir apenas algo como try (ou qualquer notação de atalho análoga) _se_ um manipulador explícito (possivelmente vazio) for fornecido em algum lugar (observe que o projeto original do rascunho não tinha tal exigência, também).

Não tenho certeza se queremos ir tão longe. Deixe-me reafirmar que muitos códigos perfeitamente finos, digamos, internos de uma biblioteca, não precisam decorar erros em todos os lugares. Não há problema em propagar erros e decorá-los antes que eles saiam dos pontos de entrada da API, por exemplo. (Na verdade, decorá-los em todos os lugares só levará a erros superdecorados que, com os verdadeiros culpados ocultos, dificultam a localização dos erros importantes; assim como o log excessivamente detalhado pode dificultar a visualização do que realmente está acontecendo).

Acho que também podemos adicionar uma função catch , que seria um bom par, então:

func a() int {
  x := randInt()
  // let's assume that this is what recruiters should "fix" for us
  // or this happens in 3rd-party package.
  if x % 1337 != 0 {
    panic("not l33t enough")
  }
  return x
}

func b() error {
  // if a() panics, then x = 0, err = error{"not l33t enough"}
  x, err := catch(a())
  if err != nil {
    return err
  }
  sendSomewhereElse(x)
  return nil
}

// which could be simplified even further

func c() error {
  x := try(catch(a()))
  sendSomewhereElse(x)
  return nil
}

neste exemplo, catch() seria recover() um pânico e return ..., panicValue .
é claro, temos um caso de canto óbvio no qual temos um func, que também retorna um erro. neste caso, acho que seria conveniente apenas passar o valor do erro.

então, basicamente, você pode usar catch() para realmente recuperar() panics e transformá-los em erros.
isso parece muito engraçado para mim, porque Go na verdade não tem exceções, mas neste caso temos um padrão try()-catch() bem legal, que também não deve explodir toda a sua base de código com algo como Java ( catch(Throwable) em Principal + throws LiterallyAnything ). você pode facilmente processar o pânico de alguém como se fossem erros comuns. Atualmente, tenho cerca de 6 milhões de LoC em Go no meu projeto atual, e acho que isso simplificaria as coisas, pelo menos para mim.

@griesemer Obrigado por sua recapitulação da discussão.

Percebo que está faltando um ponto: algumas pessoas argumentaram que deveríamos esperar com esse recurso até termos genéricos, o que esperamos nos permitir resolver esse problema de uma maneira mais elegante.

Além disso, também gosto da sugestão do @velovix e, embora aprecie que isso levante algumas questões, conforme descrito nas especificações, acho que elas podem ser facilmente respondidas de maneira razoável, como o @velovix já fez.

Por exemplo:

• O que acontece se alguém fornecer um valor de função (não um literal nil) e esse valor de função (armazenado em uma variável) for nil? => Não trate o erro, ponto final. Isso é útil caso o tratamento de erros dependa do contexto e a variável do manipulador seja definida dependendo se o tratamento de erros é necessário ou não. Não é um bug, é um recurso. :)

• Outro argumento era que é melhor ter uma declaração de nível superior de um manipulador de erros porque isso deixa muito claro que a função trata os erros. => Então defina o manipulador de erro no topo da função como uma função de fechamento nomeada e use isso, então também fica muito claro que o erro deve ser tratado. Este não é um problema sério, é mais um requisito de estilo.

Que outras preocupações existiam? Tenho certeza de que todas elas podem ser respondidas da mesma forma de maneira razoável.

Finalmente, como você diz, "uma maneira de adoçar o negócio seria apenas permitir algo como try (ou qualquer notação de atalho análoga) se um manipulador explícito (possivelmente vazio) for fornecido em algum lugar". Eu acho que se vamos prosseguir com esta proposta, devemos realmente levá-la "até aqui", para encorajar o tratamento adequado de erros "explícito é melhor que implícito".

@griesemer

Agora, o que acontece se alguém fornecer um valor de função (não um literal nil) e esse valor de função (armazenado em uma variável) for nil? Por analogia com o valor nil explícito, nenhum manuseio é necessário. Mas outros podem argumentar que isso é um bug no código.

Em teoria, isso parece uma pegadinha em potencial, embora eu esteja tendo dificuldade em conceituar uma situação razoável em que um manipulador acabaria sendo nulo por acidente. Imagino que os manipuladores geralmente venham de uma função de utilidade definida em outro lugar ou como um fechamento definido na própria função. Nenhum destes provavelmente se tornará nulo inesperadamente. Você poderia teoricamente ter um cenário em que as funções do manipulador estão sendo passadas como argumentos para outras funções, mas aos meus olhos parece um pouco exagerado. Talvez haja um padrão como este que eu não conheço.

Outro argumento era que é melhor ter uma declaração de nível superior de um manipulador de erros porque isso deixa muito claro que a função trata os erros. Daí o defer .

Como @beoran mencionou, definir o manipulador como um encerramento próximo ao topo da função seria muito semelhante em estilo, e é assim que eu pessoalmente espero que as pessoas usem manipuladores com mais frequência. Embora eu aprecie a clareza conquistada pelo fato de que todas as funções que lidam com erros usarão defer , pode ficar menos claro quando uma função precisa dinamizar sua estratégia de tratamento de erros na metade da função. Então, haverá dois defer s para olhar e o leitor terá que raciocinar sobre como eles irão interagir uns com os outros. Esta é uma situação em que acredito que um argumento de manipulador seria mais claro e ergonômico, e acho que esse será um cenário _relativamente_ comum.

É possível fazê-lo funcionar sem colchetes?

Ou seja, algo como:
a := try func(some)

@Cyberax - Como já mencionado acima, é muito essencial que você leia o documento de design cuidadosamente antes de postar. Uma vez que este é um problema de alto tráfego, com muitas pessoas inscritas.

O documento discute operadores versus funções em detalhes.

Gosto muito mais desta versão do que gostei da versão de agosto.

Acho que muito do feedback negativo, que não é totalmente contrário aos retornos sem a palavra-chave return , pode ser resumido em dois pontos:

1. as pessoas não gostam de parâmetros de resultado nomeados, que se tornariam obrigatórios na maioria dos casos
2. desencoraja a adição de contexto detalhado aos erros

Veja por exemplo:

• https://github.com/golang/go/issues/32437#issuecomment -498937169
• https://github.com/golang/go/issues/32437#issuecomment -498967099
• https://github.com/golang/go/issues/32437#issuecomment -499194787
• https://github.com/golang/go/issues/32437#issuecomment -499309304

A refutação para essas duas objeções é, respectivamente:

1. "decidimos que [parâmetros de resultado nomeados] estavam ok"
2. "Ninguém vai fazer você usar try " / não será apropriado para 100% dos casos

Eu realmente não tenho nada a dizer sobre 1 (eu não sinto muito sobre isso). Mas em relação ao 2 eu notaria que a proposta de agosto não teve esse problema, a maioria das contrapropostas também não tem esse problema.

Em particular, nem a contraproposta tryf (que foi postada independentemente duas vezes neste tópico) nem a contraproposta try(X, handlefn) (que fazia parte das iterações de design) tiveram esse problema.

Eu acho que é difícil argumentar que try , como está, afastará as pessoas da decoração de erros com contexto relevante e em direção a uma única decoração de erro genérica por função.

Por esses motivos, acho que vale a pena tentar resolver esse problema e quero propor uma possível solução:

1. Atualmente o parâmetro defer só pode ser uma função ou chamada de método. Permitir que defer também tenha um nome de função ou um literal de função, ou seja

defer func(...) {...}
defer packageName.functionName

1. Quando panic ou deferreturn encontrarem este tipo de defer eles irão chamar a função passando o valor zero para todos os seus parâmetros

2. Permitir que try tenha mais de um parâmetro

3. Quando try encontrar o novo tipo de defer, ele chamará a função passando um ponteiro para o valor do erro como o primeiro parâmetro seguido por todos os próprios parâmetros de try , exceto o primeiro.

Por exemplo, dado:

func errorfn() error {
    return errors.New("an error")
}


func f(fail bool) {
    defer func(err *error, a, b, c int) {
        fmt.Printf("a=%d b=%d c=%d\n", a, b, c)
    }
    if fail {
        try(errorfn, 1, 2, 3)
    }
}

acontecerá o seguinte:

f(false)        // prints "a=0 b=0 c=0"
f(true)         // prints "a=1 b=2 c=3"

O código em https://github.com/golang/go/issues/32437#issuecomment -499309304 por @zeebo poderia ser reescrito como:

func (c *Config) Build() error {
    defer func(err *error, msg string, args ...interface{}) {
        if *err == nil || msg == "" {
            return
        }
        *err = errors.WithMessagef(err, msg, args...)
    }
    pkgPath := try(c.load(), "load config dir")

    b := bytes.NewBuffer(nil)
    try(templates.ExecuteTemplate(b, "main", c), "execute main template")

    buf := try(format.Source(b.Bytes()), "format main template")

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)
    // ...
}

E definindo ErrorHandlef como:

func HandleErrorf(err *error, format string, args ...interface{}) {
        if *err != nil && format != "" {
                *err = fmt.Errorf(format + ": %v", append(args, *err)...)
        }
}

daria a todos os tão procurados tryf de graça, sem puxar as strings de formato fmt -style para o idioma principal.

Este recurso é compatível com versões anteriores porque defer não permite expressões de função como seu argumento. Não introduz novas palavras-chave.
As alterações que precisam ser feitas para implementá-lo, além das descritas em https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md , são:

1. ensinar o analisador sobre o novo tipo de adiamento
2. altere o verificador de tipos para verificar se dentro de uma função todos os defers que possuem uma função como parâmetro (ao invés de uma chamada) também possuem a mesma assinatura
3. altere o verificador de tipos para verificar se os parâmetros passados ​​para try correspondem à assinatura das funções passadas para defer
4. altere o back-end (?) para gerar a chamada deferproc apropriada
5. altere a implementação de try para copiar seus argumentos nos argumentos da chamada adiada quando encontrar uma chamada adiada pelo novo tipo de adiamento.

Após as complexidades do projeto check/handle , fiquei agradavelmente surpreso ao ver essa proposta muito mais simples e pragmática chegar, embora esteja desapontado por ter havido tanto retrocesso contra ela.

Reconhecidamente, muito do contra-ataque vem de pessoas que estão bastante satisfeitas com a verbosidade atual (uma posição perfeitamente razoável a ser tomada) e que, presumivelmente, não gostariam de receber qualquer proposta para aliviá-la. Para o resto de nós, acho que esta proposta atinge o ponto ideal de ser simples e semelhante ao Go, não tentar fazer muito e se encaixar bem com as técnicas de tratamento de erros existentes nas quais você sempre pode recorrer se try não fez exatamente o que você queria.

Sobre alguns pontos específicos:

1. A única coisa que não gosto na proposta é a necessidade de ter um parâmetro de retorno de erro nomeado quando defer é usado, mas, dito isso, não consigo pensar em nenhuma outra solução que não esteja em desacordo com como o resto da linguagem funciona. Então, acho que teremos que aceitar isso se a proposta for aprovada.

2. É uma pena que try não funcione bem com o pacote de teste para funções que não retornam um valor de erro. Minha própria solução preferida para isso seria ter uma segunda função interna (talvez ptry ou must ) que sempre entrasse em pânico em vez de retornar ao encontrar um erro não nulo e que poderia, portanto, ser usado com as funções acima mencionadas (incluindo main ). Embora essa ideia tenha sido rejeitada na presente iteração da proposta, tive a impressão de que era uma 'chamada de perto' e, portanto, pode ser elegível para reconsideração.

3. Eu acho que seria difícil para as pessoas entenderem o que go try(f) ou defer try(f) estavam fazendo e que é melhor, portanto, proibi-los completamente.

4. Eu concordo com aqueles que pensam que as técnicas de tratamento de erros existentes pareceriam menos detalhadas se go fmt não reescrevesse instruções if uma única linha. Pessoalmente, eu preferiria uma regra simples de que isso seria permitido para _qualquer_ instrução única if independentemente de se preocupar com o tratamento de erros ou não. Na verdade, nunca consegui entender por que isso não é permitido atualmente ao escrever funções de linha única em que o corpo é colocado na mesma linha em que a declaração é permitida.

No caso de erros de decoração

func myfunc()( err error){
try(thing())
defer func(){
err = errors.Wrap(err,"more context")
}()
}

Isso parece consideravelmente mais detalhado e doloroso do que os paradigmas existentes, e não tão conciso quanto check/handle. A variante try() sem encapsulamento é mais concisa, mas parece que as pessoas acabarão usando uma mistura de try e retornos de erro simples. Não tenho certeza se gosto da ideia de misturar tentativas e retornos de erros simples, mas estou totalmente convencido de erros de decoração (e ansioso por Is/As). Faça-me pensar que, embora isso seja sintaticamente legal, não tenho certeza se realmente gostaria de usá-lo. check/handle senti algo que eu abraçaria mais profundamente.

Eu realmente gosto da simplicidade disso e da abordagem "faça uma coisa bem". No meu interpretador GoAWK , seria muito útil - eu tenho cerca de 100 if err != nil { return nil } construções que simplificariam e organizariam, e isso está em uma base de código bastante pequena.

Eu li a justificativa da proposta para torná-la um built-in em vez de uma palavra-chave, e tudo se resume a não ter que ajustar o analisador. Mas isso não é uma quantidade relativamente pequena de dor para compiladores e criadores de ferramentas, enquanto ter os parênteses extras e os problemas de legibilidade de isso parece uma função, mas não é algo que todos os codificadores e códigos Go leitores têm que suportar. Na minha opinião, o argumento (desculpa? :-) de que "mas panic() controla o fluxo" não o corta, porque pânico e recuperação são por sua própria natureza, excepcionais , enquanto try() ser tratamento de erro normal e fluxo de controle.

Eu definitivamente apreciaria mesmo que isso acontecesse como está, mas minha forte preferência seria que o fluxo de controle normal fosse claro, ou seja, feito por meio de uma palavra-chave.

Sou a favor desta proposta. Evita minha maior ressalva sobre a proposta anterior: a não ortogonalidade de handle em relação a defer .

Gostaria de mencionar dois aspectos que acho que não foram destacados acima.

Em primeiro lugar, embora esta proposta não facilite a adição de texto de erro específico do contexto a um erro, ela _facilita_ a adição de informações de rastreamento de erro de quadro de pilha a um erro: https://play.golang.org/p /YL1MoqR08E6

Em segundo lugar, try é sem dúvida uma solução justa para a maioria dos problemas subjacentes https://github.com/golang/go/issues/19642. Para dar um exemplo desse problema, você pode usar try para evitar escrever todos os valores de retorno a cada vez. Isso também é potencialmente útil ao retornar tipos de estrutura por valor com nomes longos.

func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
    xx := int(x)
    if f.NumGlyphs() <= xx {
        try(ErrNotFound)
    }
    i := f.cached.locations[xx+0]
    j := f.cached.locations[xx+1]
    if j < i {
        try(errInvalidGlyphDataLength)
    }
    if j-i > maxGlyphDataLength {
        try(errUnsupportedGlyphDataLength)
    }
    buf, err = b.view(&f.src, int(i), int(j-i))
    return buf, i, j - i, err
}

Também gosto desta proposta.

E eu tenho um pedido.

Como make , podemos permitir que try receba um número variável de parâmetros

• tente(f):
  como acima.
  um valor de erro de retorno é obrigatório (como o último parâmetro de retorno).
  MODELO DE USO MAIS COMUM
• try(f, doPanic bool):
  como acima, mas se doPanic, então panic (err) em vez de retornar.
  Neste modo, um valor de erro de retorno não é necessário.
• tente(f, f):
  como acima, mas chame fn(err) antes de retornar.
  Neste modo, um valor de erro de retorno não é necessário.

Dessa forma, é um builtin que pode lidar com todos os casos de uso, enquanto ainda é explícito. Suas vantagens:

• sempre explícito - não há necessidade de inferir se entrar em pânico ou definir erro e retornar
• suporta manipulador específico de contexto (mas nenhuma cadeia de manipulador)
• suporta casos de uso onde não há variável de retorno de erro
• suporta a semântica must(...)

Enquanto if err !=nil { return ... err } repetitivo é certamente uma gagueira feia, eu estou com aqueles
que pensam que a proposta try() é muito baixa em legibilidade e um tanto inexplícita.
O uso de retornos nomeados também é problemático.

Se esse tipo de arrumação é necessário, por que não try(err) como açúcar sintático para
if err !=nil { return err } :

file, err := os.Open("file.go")
try(err)

para

file, err := os.Open("file.go")
if err != nil {
   return err
}

E se houver mais de um valor de retorno, try(err) poderia return t1, ... tn, err
onde t1, ... tn são os valores zero dos outros valores de retorno.

Essa sugestão pode evitar a necessidade de valores de retorno nomeados e ser,
a meu ver, mais fácil de entender e mais legível.

Melhor ainda, acho que seria:

file, try(err) := os.Open("file.go")

Ou mesmo

file, err? := os.Open("file.go")

Este último é compatível com versões anteriores (? atualmente não é permitido em identificadores).

(Esta sugestão está relacionada a https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring-themes. Mas os exemplos de temas recorrentes parecem diferentes porque isso estava em um estágio em que um identificador explícito ainda estava sendo discutido em vez de sair isso para um adiamento.)

Obrigado à equipe go por esta proposta cuidadosa e interessante.

@rogpeppe comenta se try adiciona automaticamente o quadro de pilha, não eu, estou bem com isso desencorajando a adição de contexto.

@aarzilli - Então, de acordo com sua proposta, uma cláusula de defer é obrigatória toda vez que damos parâmetros extras para tryf ?

O que acontece se eu fizer

try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)

e não escreva uma função defer?

@agnivade

O que acontece se eu fizer (...) e não escrever uma função defer?

erro de verificação de tipo.

Na minha opinião, usar try para evitar escrever todos os valores de retorno é na verdade apenas mais um golpe contra ele.

func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
    xx := int(x)
    if f.NumGlyphs() <= xx {
        try(ErrNotFound)
    }
    //...

Eu entendo completamente o desejo de evitar ter que escrever return nil, 0, 0, ErrNotFound , mas prefiro resolver isso de outra maneira.

A palavra try não significa "retornar". E é assim que está sendo usado aqui. Na verdade, eu preferiria que a proposta mudasse para que try não pudesse receber um error diretamente, porque eu nunca quero que ninguém escreva código assim ^^ . Ele lê errado . Se você mostrasse esse código para um novato, eles não teriam ideia do que essa tentativa estava fazendo.

Se quisermos uma maneira de retornar facilmente os padrões e um valor de erro, vamos resolver isso separadamente. Talvez outro builtin como

return default(ErrNotFound)

Pelo menos isso se lê com algum tipo de lógica.

Mas não vamos abusar de try para resolver algum outro problema.

@natefinch se o try embutido for nomeado check como na proposta original, seria check(err) que é consideravelmente melhor, imo.

Deixando isso de lado, não sei se é realmente um abuso escrever try(err) . Ele cai fora da definição de forma limpa. Mas, por outro lado, isso também significa que isso é legal:

a, b := try(1, f(), err)

Acho que meu principal problema com try é que é realmente apenas um panic que só sobe um nível... exceto que, diferentemente do pânico, é uma expressão, não uma declaração, então você pode esconder no meio de uma declaração em algum lugar. Isso quase o torna pior do que o pânico.

@natefinch Se você conceitua isso como um pânico que sobe um nível e depois faz outras coisas, parece muito confuso. No entanto, eu conceituo de forma diferente. Funções que retornam erros em Go estão efetivamente retornando um Result, para emprestar vagamente da terminologia de Rust. try é um utilitário que descompacta o resultado e retorna um "resultado de erro" se error != nil ou descompacta a parte T do resultado se error == nil .

Claro, em Go não temos objetos de resultado, mas é efetivamente o mesmo padrão e try parece uma codificação natural desse padrão. Acredito que qualquer solução para este problema terá que codificar algum aspecto do tratamento de erros, e try s assumir isso me parece razoável. Eu e outros estamos sugerindo estender um pouco a capacidade de try para melhor se adequar aos padrões de tratamento de erros Go existentes, mas o conceito subjacente permanece o mesmo.

@ugorji A variante try(f, bool) que você propõe soa como a must de #32219.

@ugorji A variante try(f, bool) que você propõe soa como a must de #32219.

Sim, ele é. Eu apenas senti que todos os 3 casos poderiam ser tratados com uma função interna singular e satisfazer todos os casos de uso elegantemente.

Como try() já é mágico, e ciente do valor de retorno do erro, poderia ser aumentado para também retornar um ponteiro para esse valor quando chamado na forma nula (argumento zero)? Isso eliminaria a necessidade de retornos nomeados e, acredito, ajudaria a correlacionar visualmente de onde se espera que o erro venha nas instruções de defer. Por exemplo:

func foo() error {
  defer fmt.HandleErrorf(try(), "important foo context info")
  try(bar())
  try(baz())
  try(etc())
}

@ugorji
Eu acho que o booleano em try(f, bool) tornaria difícil de ler e fácil de perder. Eu gosto da sua proposta, mas para o caso de pânico, acho que isso poderia ser deixado de fora para os usuários escreverem isso dentro do manipulador do seu terceiro marcador, por exemplo, try(f(), func(err error) { panic('at the disco'); }) , isso o torna mais explícito para os usuários do que um try(f(), true) oculto

@ugorji
Eu acho que o booleano em try(f, bool) tornaria difícil de ler e fácil de perder. Eu gosto da sua proposta, mas para o caso de pânico, acho que isso poderia ser deixado de fora para os usuários escreverem isso dentro do manipulador do seu terceiro marcador, por exemplo, try(f(), func(err error) { panic('at the disco'); }) , isso o torna mais explícito para os usuários do que um try(f(), true) oculto

Pensando melhor, tendo a concordar com sua posição e seu raciocínio, e ainda parece elegante como uma frase de efeito.

@patrick-nyt ainda é outro proponente da _sintaxe de atribuição_ para acionar um teste nil, em https://github.com/golang/go/issues/32437#issuecomment -499533464

Este conceito aparece em 13 respostas separadas à proposta de cheque/manuseio
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

f, ?return := os.Open(...)
f, ?panic  := os.Open(...)

Por quê? Porque se lê como Go 1, enquanto try() e check não.

https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md#draft -design

Uma objeção a try parece ser que é uma expressão. Suponha, em vez disso, que haja uma instrução postfix unária ? que significa retorno se não for nulo. Aqui está o exemplo de código padrão (supondo que meu pacote adiado proposto seja adicionado):

func CopyFile(src, dst string) error {
    var err error // Don't need a named return because err is explicitly named
    defer deferred.Annotate(&err, "copy %s %s", src, dst)

    r, err := os.Open(src)
    err?
    defer deferred.AnnotatedExec(&err, r.Close)

    w, err := os.Create(dst)
    err?
    defer deferred.AnnotatedExec(&err, r.Close)

    defer deferred.Cond(&err, func(){ os.Remove(dst) })
    _, err = io.Copy(w, r)

    return err
}

O exemplo pgStore:

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    err?

    defer deferred.Cond(&err, func(){ tx.Rollback() })

    var res int64 
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    // tricky bit: this would not change the value of err 
    // but the deferred.Cond would still be triggered by err being set before
    deferred.Format(err, "insert table")?

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    deferred.Format(err, "insert table2")?

    return tx.Commit()
}

Eu gosto disso do @jargv :

Como o try() já é mágico e está ciente do valor de retorno do erro, ele poderia ser aumentado para também retornar um ponteiro para esse valor quando chamado na forma nula (argumento zero)? Isso eliminaria a necessidade de retornos nomeados

Mas em vez de sobrecarregar o nome try com base no número de argumentos, acho que poderia haver outra mágica incorporada, digamos reterr ou algo assim.

Eu resumi alguns pacotes muito usados, procurando por código go que "sofre" de manipulação de erros, mas deve ter sido bem pensado antes de ser escrito, tentando descobrir que "mágica" o try() proposto faria.
Atualmente, a menos que eu tenha entendido mal a proposta, muitos deles (por exemplo, tratamento de erros não super básico) não ganhariam muito, ou teriam que ficar com o estilo "antigo" de tratamento de erros.
Exemplo de net/http/request.go:

func (r *Request) write(w io.Writer, usingProxy bool, extraHeaders Header, waitForContinue func() bool) (err error) {
`

trace := httptrace.ContextClientTrace(r.Context())
if trace != nil && trace.WroteRequest != nil {
    defer func() {
        trace.WroteRequest(httptrace.WroteRequestInfo{
            Err: err,
        })
    }()
}

// Find the target host. Prefer the Host: header, but if that
// is not given, use the host from the request URL.
//
// Clean the host, in case it arrives with unexpected stuff in it.
host := cleanHost(r.Host)
if host == "" {
    if r.URL == nil {
        return errMissingHost
    }
    host = cleanHost(r.URL.Host)
}

// According to RFC 6874, an HTTP client, proxy, or other
// intermediary must remove any IPv6 zone identifier attached
// to an outgoing URI.
host = removeZone(host)

ruri := r.URL.RequestURI()
if usingProxy && r.URL.Scheme != "" && r.URL.Opaque == "" {
    ruri = r.URL.Scheme + "://" + host + ruri
} else if r.Method == "CONNECT" && r.URL.Path == "" {
    // CONNECT requests normally give just the host and port, not a full URL.
    ruri = host
    if r.URL.Opaque != "" {
        ruri = r.URL.Opaque
    }
}
if stringContainsCTLByte(ruri) {
    return errors.New("net/http: can't write control character in Request.URL")
}
// TODO: validate r.Method too? At least it's less likely to
// come from an attacker (more likely to be a constant in
// code).

// Wrap the writer in a bufio Writer if it's not already buffered.
// Don't always call NewWriter, as that forces a bytes.Buffer
// and other small bufio Writers to have a minimum 4k buffer
// size.
var bw *bufio.Writer
if _, ok := w.(io.ByteWriter); !ok {
    bw = bufio.NewWriter(w)
    w = bw
}

_, err = fmt.Fprintf(w, "%s %s HTTP/1.1\r\n", valueOrDefault(r.Method, "GET"), ruri)
if err != nil {
    return err
}

// Header lines
_, err = fmt.Fprintf(w, "Host: %s\r\n", host)
if err != nil {
    return err
}
if trace != nil && trace.WroteHeaderField != nil {
    trace.WroteHeaderField("Host", []string{host})
}

// Use the defaultUserAgent unless the Header contains one, which
// may be blank to not send the header.
userAgent := defaultUserAgent
if r.Header.has("User-Agent") {
    userAgent = r.Header.Get("User-Agent")
}
if userAgent != "" {
    _, err = fmt.Fprintf(w, "User-Agent: %s\r\n", userAgent)
    if err != nil {
        return err
    }
    if trace != nil && trace.WroteHeaderField != nil {
        trace.WroteHeaderField("User-Agent", []string{userAgent})
    }
}

// Process Body,ContentLength,Close,Trailer
tw, err := newTransferWriter(r)
if err != nil {
    return err
}
err = tw.writeHeader(w, trace)
if err != nil {
    return err
}

err = r.Header.writeSubset(w, reqWriteExcludeHeader, trace)
if err != nil {
    return err
}

if extraHeaders != nil {
    err = extraHeaders.write(w, trace)
    if err != nil {
        return err
    }
}

_, err = io.WriteString(w, "\r\n")
if err != nil {
    return err
}

if trace != nil && trace.WroteHeaders != nil {
    trace.WroteHeaders()
}

// Flush and wait for 100-continue if expected.
if waitForContinue != nil {
    if bw, ok := w.(*bufio.Writer); ok {
        err = bw.Flush()
        if err != nil {
            return err
        }
    }
    if trace != nil && trace.Wait100Continue != nil {
        trace.Wait100Continue()
    }
    if !waitForContinue() {
        r.closeBody()
        return nil
    }
}

if bw, ok := w.(*bufio.Writer); ok && tw.FlushHeaders {
    if err := bw.Flush(); err != nil {
        return err
    }
}

// Write body and trailer
err = tw.writeBody(w)
if err != nil {
    if tw.bodyReadError == err {
        err = requestBodyReadError{err}
    }
    return err
}

if bw != nil {
    return bw.Flush()
}
return nil

}
`

ou conforme usado em um teste completo como pprof/profile/profile_test.go:
`
func checkAggregation(prof *Profile, a *aggTest) error {
// Verifique se o número total de amostras para as linhas foi preservado.
total := int64(0)

samples := make(map[string]bool)
for _, sample := range prof.Sample {
    tb := locationHash(sample)
    samples[tb] = true
    total += sample.Value[0]
}

if total != totalSamples {
    return fmt.Errorf("sample total %d, want %d", total, totalSamples)
}

// Check the number of unique sample locations
if a.rows != len(samples) {
    return fmt.Errorf("number of samples %d, want %d", len(samples), a.rows)
}

// Check that all mappings have the right detail flags.
for _, m := range prof.Mapping {
    if m.HasFunctions != a.function {
        return fmt.Errorf("unexpected mapping.HasFunctions %v, want %v", m.HasFunctions, a.function)
    }
    if m.HasFilenames != a.fileline {
        return fmt.Errorf("unexpected mapping.HasFilenames %v, want %v", m.HasFilenames, a.fileline)
    }
    if m.HasLineNumbers != a.fileline {
        return fmt.Errorf("unexpected mapping.HasLineNumbers %v, want %v", m.HasLineNumbers, a.fileline)
    }
    if m.HasInlineFrames != a.inlineFrame {
        return fmt.Errorf("unexpected mapping.HasInlineFrames %v, want %v", m.HasInlineFrames, a.inlineFrame)
    }
}

// Check that aggregation has removed finer resolution data.
for _, l := range prof.Location {
    if !a.inlineFrame && len(l.Line) > 1 {
        return fmt.Errorf("found %d lines on location %d, want 1", len(l.Line), l.ID)
    }

    for _, ln := range l.Line {
        if !a.fileline && (ln.Function.Filename != "" || ln.Line != 0) {
            return fmt.Errorf("found line %s:%d on location %d, want :0",
                ln.Function.Filename, ln.Line, l.ID)
        }
        if !a.function && (ln.Function.Name != "") {
            return fmt.Errorf(`found file %s location %d, want ""`,
                ln.Function.Name, l.ID)
        }
    }
}

return nil

}
`
Estes são dois exemplos em que posso pensar em que se diria: "Gostaria de uma melhor opção de tratamento de erros"

Alguém pode demonstrar como isso melhoraria usando try() ?

Sou principalmente a favor desta proposta.

Minha principal preocupação, compartilhada com muitos comentaristas, é sobre parâmetros de resultado nomeados. A proposta atual certamente incentiva muito mais o uso de parâmetros de resultado nomeados e acho que isso seria um erro. Não acredito que isso seja simplesmente uma questão de estilo, como afirma a proposta: resultados nomeados são uma característica sutil da linguagem que, em muitos casos, torna o código mais propenso a bugs ou menos claro. Após ~8 anos lendo e escrevendo código Go, eu realmente só uso parâmetros de resultado nomeados para dois propósitos:

• Documentação dos parâmetros de resultado
• Manipulando um valor de resultado (geralmente um error ) dentro de um defer

Para atacar este problema de uma nova direção, aqui está uma ideia que eu não acho que se alinha com nada que tenha sido discutido no documento de design ou neste tópico de comentários sobre o problema. Vamos chamá-lo de "erro-defer":

Permitir que o defer seja usado para chamar funções com um parâmetro de erro implícito.

Então, se você tem uma função

func f(err error, t1 T1, t2 T2, ..., tn Tn) error

Então, em uma função g onde o último parâmetro de resultado tem o tipo error (ou seja, qualquer função onde try pode ser usado), uma chamada para f pode ser adiado da seguinte forma:

func g() (R0, R0, ..., error) {
    defer f(t0, t1, ..., tn) // err is implicit
}

A semântica de error-defer é:

1. A chamada adiada para f é chamada com o último parâmetro de resultado de g como o primeiro parâmetro de entrada de f
2. f só é chamado se esse erro não for nulo
3. O resultado de f é atribuído ao último parâmetro de resultado de g

Então, para usar um exemplo do antigo documento de design de tratamento de erros, usando error-defer e try, poderíamos fazer

func printSum(a, b string) error {
    defer func(err error) error {
        return fmt.Errorf("printSum(%q + %q): %v", a, b, err)
    }()
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x+y)
    return nil
}

Veja como HandleErrorf funcionaria:

func printSum(a, b string) error {
    defer handleErrorf("printSum(%q + %q)", a, b)
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x+y)
    return nil
}

func handleErrorf(err error, format string, args ...interface{}) error {
    return fmt.Errorf(format+": %v", append(args, err)...)
}

Um caso de canto que precisaria ser resolvido é como lidar com casos em que é ambíguo qual forma de adiamento estamos usando. Acho que isso só acontece com funções (muito incomuns) com assinaturas assim:

func(error, ...error) error

Parece razoável dizer que este caso é tratado da maneira sem adiamento de erros (e isso preserva a compatibilidade com versões anteriores).

Pensando nessa ideia nos últimos dias, é um pouco mágico, mas evitar parâmetros de resultado nomeados é uma grande vantagem a seu favor. Como try encoraja mais o uso de defer para manipulação de erros, faz algum sentido que defer possa ser estendido para melhor se adequar a esse propósito. Além disso, há uma certa simetria entre try e error-defer.

Finalmente, os adiamentos de erro são úteis hoje mesmo sem tentativa, pois suplantam o uso de parâmetros de resultado nomeados para manipular retornos de erro. Por exemplo, aqui está uma versão editada de algum código real:

// GetMulti retrieves multiple files through the cache at once and returns its
// results as a slice parallel to the input.
func (c *FileCache) GetMulti(keys []string) (_ []*File, err error) {
    files := make([]*file, len(keys))

    defer func() {
        if err != nil {
            // Return any successfully retrieved files.
            for _, f := range files {
                if f != nil {
                    c.put(f)
                }
            }
        }
    }()

    // ...
}

Com error-defer, isso se torna:

// GetMulti retrieves multiple files through the cache at once and returns its
// results as a slice parallel to the input.
func (c *FileCache) GetMulti(keys []string) ([]*File, error) {
    files := make([]*file, len(keys))

    defer func(err error) error {
        // Return any successfully retrieved files.
        for _, f := range files {
            if f != nil {
                c.put(f)
            }
        }
        return err
    }()

    // ...
}

@beoran Em relação ao seu comentário de que devemos esperar pelos genéricos. Os genéricos não ajudarão aqui - por favor, leia o FAQ .

Em relação às suas sugestões sobre o comportamento padrão de 2 argumentos try do @velovix : Como eu disse antes , sua ideia do que é a escolha obviamente razoável é o pesadelo de outra pessoa.

Posso sugerir que continuemos esta discussão uma vez que um amplo consenso evolui de que try com um manipulador de erro explícito é uma ideia melhor do que o mínimo atual try . Nesse ponto, faz sentido discutir os detalhes de tal design.

(Gosto de ter um manipulador, aliás. É uma de nossas propostas anteriores. E se adotarmos try como está, ainda podemos avançar para um try com um manipulador em um -compatível - pelo menos se o manipulador for opcional. Mas vamos dar um passo de cada vez.)

@aarzilli Obrigado pela sua sugestão .

Enquanto os erros de decoração forem opcionais, as pessoas tenderão a não fazê-lo (afinal, é um trabalho extra). Veja também meu comentário aqui .

Então, eu não acho que os try _desanimam_ as pessoas de decorar erros (eles já estão desencorajados mesmo com o if pelo motivo acima); é que try não _incentiva_ isso.

(Uma maneira de incentivá-lo é vinculá-lo a try : só se pode usar try se também decorar o erro ou optar por não participar explicitamente.)

Mas voltando às suas sugestões: acho que você está introduzindo muito mais maquinário aqui. Alterar a semântica de defer apenas para fazê-la funcionar melhor para try não é algo que gostaríamos de considerar, a menos que essas alterações defer sejam benéficas de uma maneira mais geral. Além disso, sua sugestão une defer com try e assim torna ambos os mecanismos menos ortogonais; algo que gostaríamos de evitar.

Mas, mais importante, duvido que você queira forçar todos a escrever um defer apenas para que possam usar try . Mas sem fazer isso, voltamos à estaca zero: as pessoas tenderão a não decorar erros.

(Eu gosto de ter um manipulador, por falar nisso. É uma de nossas propostas anteriores. E se adotarmos try como está, ainda podemos avançar para uma tentativa com um manipulador de maneira compatível com o futuro - pelo menos se o manipulador for opcional. Mas vamos dar um passo de cada vez.)

Claro, talvez uma abordagem de várias etapas seja o caminho a seguir. Se adicionarmos um argumento handler opcional no futuro, ferramentas podem ser criadas para avisar o escritor de um try não tratado no mesmo espírito que a ferramenta errcheck . De qualquer forma, agradeço seu feedback!

@alanfo Obrigado pelo seu feedback positivo.

Sobre os pontos que você levantou:

1) Se o único problema com try é o fato de que será necessário nomear um retorno de erro para que possamos decorar um erro via defer , acho que estamos bem. Se nomear o resultado for um problema real, podemos resolvê-lo. Um mecanismo simples em que posso pensar seria uma variável pré-declarada que é um alias para um resultado de erro (pense nisso como mantendo o erro que acionou o try mais recente). Pode haver ideias melhores. Não propusemos isso porque já existe um mecanismo na linguagem, que é dar nome ao resultado.
2) try e testes: Isso pode ser resolvido e feito para funcionar. Veja o documento detalhado.
3) Isso é explicitamente abordado no documento detalhado.
4) Reconhecido.

@benhoyt Obrigado pelo seu feedback positivo.

Se o principal argumento contra esta proposta é o fato de que try é um built-in, estamos em um ótimo lugar. Usar um built-in é simplesmente uma solução pragmática para o problema de compatibilidade com versões anteriores (isso não causa trabalho extra para o analisador e ferramentas etc. - mas isso é apenas um bom benefício colateral, não o principal motivo). Há também alguns benefícios em ter que escrever parênteses, isso é discutido em detalhes no documento de design (seção sobre Propriedades do design proposto).

Dito tudo isso, se usar um built-in é o showtopper, devemos considerar a palavra-chave try . Não será compatível com o código existente, pois a palavra-chave pode entrar em conflito com os identificadores existentes.

(Para ser completo, há também a opção de um operador como ? , que seria compatível com versões anteriores. Mas não me parece a melhor escolha para uma linguagem como Go. Mas, novamente, se isso é tudo o que é preciso para tornar try palatável, talvez devêssemos considerá-lo.)

@ugorji Obrigado pelo seu feedback positivo.

try pode ser estendido para receber um argumento adicional. Nossa preferência seria pegar apenas uma função com assinatura func (error) error . Se você quiser entrar em pânico, é fácil fornecer uma função auxiliar de uma linha:

func doPanic(err error) error { panic(err) }

Melhor manter o design de try simples.

@patrick-nyt O que você está sugerindo :

file, err := os.Open("file.go")
try(err)

será possível com a proposta atual.

@dpinela , @ugorji Leia também o documento de design sobre must vs try . É melhor manter try o mais simples possível. must é um "padrão" comum em expressões de inicialização, mas não há necessidade urgente de "corrigir" isso.

@jargv Obrigado pela sua sugestão . Esta é uma ideia interessante (veja também o meu comentário aqui sobre este assunto). Para resumir:

• try(x) funciona como proposto
• try() retorna um *error apontando para o resultado do erro

Esta seria, de fato, outra maneira de obter o resultado sem precisar nomeá-lo.

@cespare A sugestão de @jargv me parece muito mais simples do que você está propondo . Ele resolve o mesmo problema de acesso ao erro de resultado. O que você acha?

Conforme https://github.com/golang/go/issues/32437#issuecomment -499320588:

func doPanic(err error) error { panic(err) }

Prevejo que esta função seria bastante comum. Isso poderia ser predefinido em "builtin" (ou em outro lugar em um pacote padrão, por exemplo errors )?

Pena que você não prevê genéricos poderosos o suficiente para implementar
tentar, eu realmente esperava que fosse possível fazê-lo.

Sim, esta proposta pode ser um primeiro passo, embora eu não veja muita utilidade em
eu mesmo como está agora.

Concedido, esta questão talvez tenha muito foco em alternativas detalhadas,
mas isso mostra que muitos participantes não estão completamente satisfeitos com
isto. O que parece faltar é um amplo consenso sobre essa proposta...

Op vr 7 jun. 2019 01:04 schreef pj [email protected] :

Asper #32437 (comentário)
https://github.com/golang/go/issues/32437#issuecomment-499320588 :

func doPanic(err error) error { panic(err) }

Prevejo que esta função seria bastante comum. Isso poderia ser predefinido
em "embutido"?

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=AAARM6OOOLLYO5ZCE6VVL2TPZGJWRA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXEMYZYissue#comentário-499
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AAARM6K5AOR2DES4QDTNLSTPZGJWRANCNFSM4HTGCZ7Q
.

@pjebs , escrevi a função equivalente dezenas de vezes. Eu costumo chamar de “orDie” ou “check”. É tão simples que não há necessidade real de torná-lo parte da biblioteca padrão. Além disso, pessoas diferentes podem querer fazer login ou qualquer outra coisa antes do término.

@beoran Talvez você possa expandir a conexão entre genéricos e tratamento de erros. Quando penso neles, parecem duas coisas diferentes. Generics não é um catch all que pode resolver todos os problemas com o idioma. É a capacidade de escrever uma única função que pode operar em vários tipos.

Essa proposta específica de tratamento de erros tenta reduzir o clichê introduzindo uma função pré-declarada try que altera o controle de fluxo em algumas circunstâncias. Os genéricos nunca mudarão o fluxo de controle. Então eu realmente não vejo a relação.

Minha reação inicial a isso foi um 👎, pois imaginei que lidar com várias chamadas propensas a erros em uma função tornaria o identificador de erro defer confuso. Depois de ler toda a proposta, mudei minha reação para um ❤️ e 👍, pois aprendi que isso ainda pode ser alcançado com complexidade relativamente baixa.

@carlmjohnson Sim, é simples, mas...

Eu escrevi a função equivalente dezenas de vezes.

As vantagens de uma função pré-declarada são:

1. Podemos uni-lo
2. Não precisamos redeclarar a função err => panic em cada pacote que usamos ou manter um local comum para ela. Como é comum provavelmente a todos na comunidade Go, o "pacote padrão" é _ o _ local comum para ele.

@griesemer Com a variante do manipulador de erros da proposta try original, o requisito da função abrangente para retornar o erro agora não é mais necessário.

Quando perguntei pela primeira vez sobre o err => panic, fui apontado que a proposta considerava, mas considerava muito perigoso (por boas razões). Mas se fizermos o uso de try() sem um manipulador de erros em um cenário em que a função abrangente não retorna erro, transformá-lo em um erro de tempo de compilação alivia a preocupação discutida na proposta

@pjebs O requisito da função abrangente para retornar um erro não era necessário no design original _se_ um manipulador de erro foi fornecido. Mas é apenas mais uma complicação de try . É _muito_ melhor mantê-lo simples. Em vez disso, seria mais claro ter uma função must separada, que sempre entra em pânico em caso de erro (mas, caso contrário, é como try ). Então é óbvio o que acontece no código e não é preciso olhar para o contexto.

A principal atração de ter um must seria que ele poderia ser usado com testes de unidade; especialmente se o pacote testing foi ajustado adequadamente para se recuperar dos pânicos causados ​​por must e reportá-los como falhas de teste de uma maneira agradável. Mas por que adicionar mais um novo mecanismo de linguagem quando podemos apenas ajustar o pacote de teste para também aceitar a função de teste da forma TestXxx(t *testing.T) error ? Se eles retornarem um erro, o que parece bastante natural afinal (talvez devêssemos ter feito isso desde o início), então try funcionará bem. Testes locais precisarão de um pouco mais de trabalho, mas provavelmente é factível.

O outro uso relativamente comum para must é em expressões de inicialização global ( must(regexp.Compile... , etc.). Se seria um "bom ter", mas isso não necessariamente o eleva ao nível necessário para um novo recurso de linguagem.

@griesemer Dado que must está vagamente relacionado a try , e dado que o impulso é para try ser implementado, você não acha que é bom considerar must ao mesmo tempo - mesmo que seja apenas um "bom ter".

As chances são de que, se não for discutido nesta rodada, simplesmente não será implementado/considerado seriamente, pelo menos por mais de 3 anos (ou talvez nunca). A sobreposição na discussão também seria boa, em vez de começar do zero e reciclar as discussões.

Muitas pessoas afirmaram que must complementa try muito bem.

@pjebs Certamente não parece que haja algum "momento para try ser implementado" agora... - E também postamos isso há dois dias. Nem nada foi decidido. Vamos dar um tempo.

Não nos escapou que must se encaixa bem com try , mas isso não é o mesmo que torná-lo parte da linguagem. Só começamos a explorar este espaço com um grupo mais amplo de pessoas. Nós realmente não sabemos ainda o que pode surgir a favor ou contra. Obrigado.

Depois de passar horas lendo todos os comentários e o documento de design detalhado, eu queria adicionar minhas opiniões a esta proposta.

Farei o meu melhor para respeitar o pedido de @ianlancetaylor não apenas para reafirmar os pontos anteriores, mas para adicionar novos comentários à discussão. No entanto, acho que não posso fazer os novos comentários sem fazer referência aos comentários anteriores.

Preocupações

Sobrecarga infeliz de adiar

A preferência por sobrecarregar a natureza óbvia e direta de defer como alarmante. Se eu escrever defer closeFile(f) isso é direto e óbvio para mim o que está acontecendo e por quê; no final da função que será chamada. E enquanto usar defer para panic() e recover() é menos óbvio, eu raramente ou nunca o uso e quase nunca o vejo ao ler o código de outra pessoa.

Spoo para sobrecarregar defer para também lidar com erros não é óbvio e confuso. Por que a palavra-chave defer ? defer não significa _"Fazer mais tarde"_ em vez de _"Talvez até mais tarde?"_

Também há a preocupação mencionada pela equipe Go sobre o desempenho defer . Dado isso, parece duplamente lamentável que defer esteja sendo considerado para o fluxo de código _"hot path"_.

Nenhuma estatística verificando um caso de uso significativo

Como o @prologic mencionou, essa proposta try() é baseada em uma grande porcentagem de código que usaria esse caso de uso ou é baseada na tentativa de aplacar aqueles que reclamaram do tratamento de erros do Go?

Eu gostaria de saber como fornecer estatísticas da minha base de código sem revisar exaustivamente todos os arquivos e fazer anotações; Eu não sei como @prologic foi capaz, embora feliz por ele ter feito isso.

Mas, curiosamente, eu ficaria surpreso se try() abordasse 5% dos meus casos de uso e suspeitaria que isso abordaria menos de 1%. Você tem certeza de que outros têm resultados muito diferentes? Você pegou um subconjunto da biblioteca padrão e tentou ver como seria aplicado?

Porque sem estatísticas conhecidas de que isso é apropriado para uma grande quantidade de código em estado selvagem, eu tenho que perguntar se essa nova mudança complicada na linguagem que exigirá que todos aprendam os novos conceitos realmente aborda um número atraente de casos de uso?

Torna mais fácil para os desenvolvedores ignorarem erros

Esta é uma repetição total do que os outros têm comentários, mas o que basicamente fornecer try() é análogo em muitos aspectos a simplesmente abraçar o seguinte como código idomático, e este é um código que nunca encontrará seu caminho em nenhum código -respeitando os navios do desenvolvedor:

f, _ := os.Open(filename)

Eu sei que posso ser melhor em meu próprio código, mas também sei que muitos de nós dependem da generosidade de outros desenvolvedores Go que publicam alguns pacotes tremendamente úteis, mas pelo que vi em _"Other People's Code(tm)"_ as melhores práticas no tratamento de erros são frequentemente ignoradas.

Então, sério, nós realmente queremos tornar mais fácil para os desenvolvedores ignorarem erros e permitir que eles poluam o GitHub com pacotes não robustos?

Pode (principalmente) já implementar try() no userland

A menos que eu entenda mal a proposta - o que provavelmente faço - aqui está try() no Go Playground implementado em userland , embora com apenas um (1) valor de retorno e retornando uma interface em vez do tipo esperado:

package main

import (
    "errors"
    "fmt"
    "strings"
)
func main() {
    defer func() {
        r := recover()
        if r != nil && strings.HasPrefix(r.(string),"TRY:") {
            fmt.Printf("Ouch! %s",strings.TrimPrefix(r.(string),"TRY: "))
        }
    }()
    n := try(badjuju()).(int)
    fmt.Printf("Just chillin %dx!",n)   
}
func badjuju() (int,error) {
    return 10, errors.New("this is a really bad error")
}
func try(args ...interface{}) interface{} {
    err,ok := args[1].(error)
    if ok && err != nil {
        panic(fmt.Sprintf("TRY: %s",err.Error()))
    }
    return args[0]
}

Assim, o usuário poderia adicionar um try2() , try3() e assim por diante, dependendo de quantos valores de retorno eles precisassem retornar.

Mas Go precisaria apenas de um (1) recurso de linguagem simples _ mas universal _ para permitir que os usuários que desejam try() implementem seu próprio suporte, embora um que ainda exija declaração de tipo explícita. Adicione um recurso _(totalmente compatível com versões anteriores)_ para um Go func para retornar um número variável de valores de retorno, por exemplo:

func try(args ...interface{}) ...interface{} {
    err,ok := args[1].(error)
    if ok && err != nil {
        panic(fmt.Sprintf("TRY: %s",err.Error()))
    }
    return args[0:len(args)-2]
}

E se você abordar os genéricos primeiro, as asserções de tipo nem serão necessárias _(embora eu ache que os casos de uso para genéricos devam ser reduzidos adicionando builtins para abordar os casos de uso genéricos em vez de adicionar a semântica confusa e salada de sintaxe de genéricos de Java et. al.)_

Falta de obviedade

Ao estudar o código da proposta, descobri que o comportamento não é óbvio e um pouco difícil de raciocinar.

Quando vejo try() envolvendo uma expressão, o que acontecerá se um erro for retornado?

O erro será simplesmente ignorado? Ou ele pulará para o primeiro ou o mais recente defer , e se assim for, ele definirá automaticamente uma variável chamada err dentro do encerramento que, ou ele passará como um parâmetro _(I não vê um parâmetro?)_. E se não for um nome de erro automático, como nomeio? E isso significa que não posso declarar minha própria variável err na minha função, para evitar conflitos?

E ele vai chamar todos os defer s? Na ordem inversa ou na ordem normal?

Ou ele retornará tanto do fechamento quanto do func onde o erro foi retornado? _(Algo que eu nunca teria considerado se não tivesse lido aqui palavras que implicam isso.)_

Depois de ler a proposta e todos os comentários até agora, honestamente, ainda não sei as respostas para as perguntas acima. É esse o tipo de recurso que queremos adicionar a uma linguagem cujos defensores defendem como sendo _"Capitão Óbvio?"_

Falta de controle

Usando defer , parece que o único controle que os desenvolvedores teriam é ramificar para _(o mais recente?)_ defer . Mas na minha experiência com qualquer método além de um func trivial, geralmente é mais complicado do que isso.

Muitas vezes, acho útil compartilhar aspectos do tratamento de erros em um func — ou mesmo em um package — mas também ter um tratamento mais específico compartilhado em um ou mais outros pacotes.

Por exemplo, posso chamar cinco (5) func chamadas que retornam um error() de dentro de outro func ; vamos rotulá-los A() , B() , C() , D() e E() . Eu posso precisar C() para ter seu próprio tratamento de erros, A() , B() , D() e E() para compartilhar algum tratamento de erros, e B() e E() para ter manuseio específico.

Mas não acredito que seja possível fazer isso com esta proposta. Pelo menos não facilmente.

Ironicamente, no entanto, Go já possui recursos de linguagem que permitem um alto nível de flexibilidade que não precisa ser limitado a um pequeno conjunto de casos de uso; func s e encerramentos. Então minha pergunta retórica é:

_ "Por que não podemos simplesmente adicionar pequenas melhorias à linguagem existente para resolver esses casos de uso e não precisar adicionar novas funções internas ou aceitar semânticas confusas?" _

É uma pergunta retórica porque pretendo apresentar uma proposta como alternativa, que concebi durante o estudo desta proposta e considerando todos os seus inconvenientes.

Mas eu discordo, isso virá mais tarde e este comentário é sobre por que a proposta atual precisa ser reconsiderada.

Falta de suporte declarado para break

Isso pode parecer que sai do campo esquerdo, pois a maioria das pessoas usa retornos antecipados para tratamento de erros, mas descobri que é preferível usar break para tratamento de erros envolvendo a maior parte ou toda uma função antes de return .

Eu usei essa abordagem por um tempo e seus benefícios em facilitar a refatoração por si só a tornam preferível a return , mas ela tem vários outros benefícios, incluindo ponto de saída único e capacidade de encerrar uma seção de uma função antecipadamente, mas ainda ser capaz de executar limpeza _(provavelmente por isso raramente uso defer , que acho mais difícil de raciocinar em termos de fluxo de programa.)_

Para usar break em vez de um retorno antecipado use um loop for range "1" {...} para criar um bloco para o intervalo sair de _(na verdade eu crio um pacote chamado only que contém apenas uma constante chamado Once com um valor de "1" ):_

func (me *Config) WriteFile() (err error) {
    for range only.Once {
        var j []byte
        j, err = json.MarshalIndent(me, "", "    ")
        if err != nil {
            err = fmt.Errorf("unable to marshal config; %s", 
                err.Error(),
            )
            break
        }
        err = me.MaybeMakeDir(me.GetDir(), os.ModePerm)
        if err != nil {
            err = fmt.Errorf("unable to make directory'%s'; %s", 
                me.GetDir(), 
                err.Error(),
            )
            break
        }
        err = ioutil.WriteFile(string(me.GetFilepath()), j, os.ModePerm)
        if err != nil {
            err = fmt.Errorf("unable to write to config file '%s'; %s", 
                me.GetFilepath(), 
                err.Error(),
            )
            break
        }
    }
    return err
}

Eu pretendo escrever sobre o padrão em um futuro próximo e discutir as várias razões pelas quais eu descobri que ele funciona melhor do que os retornos antecipados.

Mas eu discordo. Minha razão de trazê-lo aqui é que eu teria que Go para implementar o tratamento de erros que assume return s inicial e ignora o uso break para tratamento de erros

Minha opinião err == nil é problemática

Como digressão adicional, quero trazer à tona a preocupação que senti sobre o tratamento de erros idiomáticos em Go. Embora eu acredite muito na filosofia do Go de lidar com erros quando eles ocorrem versus usar o tratamento de exceções, sinto que o uso de nil para indicar que nenhum erro é problemático porque muitas vezes acho que gostaria de retornar uma mensagem de sucesso de uma rotina — para uso em respostas de API — e não apenas retornar um valor diferente de zero apenas quando houver um erro.

Então, para o Go 2, eu realmente gostaria de ver o Go considerar a adição de um novo tipo interno de status e três funções internas iserror() , iswarning() , issuccess() . status poderia implementar error — permitindo muita compatibilidade com versões anteriores e um nil passado para issuccess() retornaria true — mas status teria um estado interno adicional para o nível de erro, de modo que o teste do nível de erro sempre fosse feito com uma das funções internas e, idealmente, nunca com uma verificação nil . Isso permitiria algo como a seguinte abordagem:

func (me *Config) WriteFile() (sts status) {
    for range only.Once {
        var j []byte
        j, sts = json.MarshalIndent(me, "", "    ")
        if iserror(sts) {
            sts.AddMessage("unable to marshal config")
            break
        }
        sts = me.MaybeMakeDir(me.GetDir(), os.ModePerm)
        if iserror(sts) {
            sts.AddMessage("unable to make directory'%s'", me.GetDir())
            break
        }
        sts = ioutil.WriteFile(string(me.GetFilepath()), j, os.ModePerm)
        if iserror(sts) {
            sts.AddMessage("unable to write to config file '%s'", 
                me.GetFilepath(), 
            )
            break
        }
        sts = fmt.Status("config file written")
    }
    return sts
}

Eu já estou usando uma abordagem userland em um pacote de uso interno de nível pré-beta que é semelhante ao acima para tratamento de erros. Francamente , gasto muito menos tempo pensando em como estruturar o código ao usar essa abordagem do que quando estava tentando seguir o tratamento de erros idiomáticos do Go.

Se você acha que há alguma chance de evoluir o código idiomático Go para essa abordagem, leve isso em consideração ao implementar o tratamento de erros, inclusive ao considerar esta proposta try() .

_"Não é para todos"_ justificação

Uma das principais respostas da equipe Go foi _"Novamente, esta proposta não tenta resolver todas as situações de tratamento de erros."_
E essa é provavelmente a preocupação mais preocupante, do ponto de vista da governança.

Essa nova mudança complicada na linguagem que exigirá que todos aprendam os novos conceitos realmente aborda um número atraente de casos de uso?

E essa não é a mesma justificativa que os membros da equipe principal negaram inúmeras solicitações de recursos da comunidade? A seguir está uma citação direta de um comentário feito por um membro da equipe Go em uma resposta arquetípica a uma solicitação de recurso enviada há cerca de 2 anos _(não estou nomeando a pessoa ou a solicitação de recurso específica porque esta discussão não deve ser possível as pessoas, mas sim sobre a língua):_

_"Um novo recurso de linguagem precisa de casos de uso atraentes. Todos os recursos de linguagem são úteis, ou ninguém os proporia. A questão é: eles são úteis o suficiente para justificar a complicação da linguagem e exigir que todos aprendam os novos conceitos? Quais são os usos atraentes casos aqui? Como as pessoas usarão isso? Por exemplo, as pessoas esperariam poder... e se sim, como elas fariam isso? Esta proposta faz mais do que deixar você...?"
— Um membro central da equipe Go

Francamente, quando vi essas respostas, senti um de dois sentimentos:

1. Indignação se for uma característica com a qual concordo, ou
2. Euforia se for uma característica com a qual não concordo.

Mas em ambos os casos meus sentimentos foram/são irrelevantes; Eu entendo e concordo que parte da razão pela qual o Go é o idioma em que muitos de nós escolhemos desenvolver é por causa dessa guarda zelosa da pureza do idioma.

E é por isso que essa proposta me incomoda tanto, porque a equipe principal do Go parece estar se aprofundando nessa proposta no mesmo nível de alguém que quer dogmaticamente um recurso esotérico que não há como a comunidade Go jamais tolerará.

_(E eu realmente espero que a equipe não atire no mensageiro e tome isso como uma crítica construtiva de alguém que quer ver Go continuar sendo o melhor que pode ser para todos nós, pois eu teria que ser considerado "Persona non grata" por a equipe principal.)_

Se exigir um conjunto atraente de casos de uso do mundo real é o padrão para todas as propostas de recursos geradas pela comunidade, não deveria ser o mesmo padrão para _ todas _ propostas de recursos?

Aninhamento de try()

Isso também foi abordado por alguns, mas quero fazer uma comparação entre try() e a solicitação contínua de operadores ternários. Citando os comentários de outro membro da equipe Go cerca de 18 meses atrás:

_"quando "programando em grande escala" (grandes bases de código com grandes equipes por longos períodos de tempo), o código é lido com MUITO mais frequência do que é escrito, então otimizamos a legibilidade, não a capacidade de escrita."_

Uma das razões _primárias_ declaradas para não adicionar operadores ternários é que eles são difíceis de ler e/ou fáceis de interpretar mal quando aninhados. No entanto, o mesmo pode ser verdade para instruções try() aninhadas como try(try(try(to()).parse().this)).easily()) .

Razões adicionais para argumentar contra os operadores ternários são que eles são _"expressões"_ com o argumento de que expressões aninhadas podem adicionar complexidade. Mas try() também não cria uma expressão aninhável?

Agora, alguém aqui disse _"Acho que exemplos como [aninhados try() s] não são realistas"_ e essa afirmação não foi contestada.

Mas se as pessoas aceitam como postulado que os desenvolvedores não aninham try() , então por que a mesma deferência não é dada aos operadores ternários quando as pessoas dizem _"Eu acho que operadores ternários profundamente aninhados são irreais?"_

Conclusão para este ponto, acho que se o argumento contra os operadores ternários é realmente válido, então eles também devem ser considerados argumentos válidos contra esta proposta try() .

Resumindo

No momento em que este texto foi escrito, os votos negativos de 58% para votos positivos de 42% . Acho que isso por si só deve ser suficiente para indicar que esta é uma proposta divisiva o suficiente para que seja hora de retornar à prancheta sobre essa questão.

fwiw

PS Para ser mais irônico, acho que devemos seguir a sabedoria parafraseada de Yoda:

_"Não há try() . Apenas do() ."_

@ianlancetaylor

@beoran Talvez você possa expandir a conexão entre genéricos e tratamento de erros.

Não falando por @beoran , mas no meu comentário de alguns minutos atrás, você verá que, se tivéssemos genéricos _(mais parâmetros de retorno variadic)_, poderíamos construir nosso próprio try() .

No entanto - e vou repetir o que disse acima sobre genéricos aqui onde será mais fácil de ver:

_" Acho que os casos de uso para genéricos devem ser reduzidos adicionando builtins para abordar os casos de uso genéricos em vez de adicionar a semântica confusa e salada de sintaxe de genéricos de Java et. al.)"_

@ianlancetaylor

Ao tentar formular uma resposta para sua pergunta, tentei implementar a função try no Go como está e, para minha alegria, na verdade já é possível emular algo bem parecido:

func try(v interface{}, err error) interface{} {
   if err != nil { 
     panic(err)
   }
   return v
}

Veja aqui como pode ser usado: https://play.golang.org/p/Kq9Q0hZHlXL

As desvantagens dessa abordagem são:

1. Um resgate adiado é necessário, mas com try como nesta proposta, um manipulador adiado também é necessário se quisermos fazer o tratamento de erros adequado. Então eu sinto que isso não é uma desvantagem séria. Poderia até ser melhor se Go tivesse algum tipo de super(arg1, ..., argn) embutido que faz com que o chamador do chamador, um nível acima da pilha de chamadas, retorne com os argumentos fornecidos arg1,...argn, uma espécie de super retorno Se você for.
2. Este try que implementei só pode funcionar com uma função que retorna um único resultado e um erro.
3. Você precisa digitar assert os resultados da interface vazia retornados.

Genéricos suficientemente poderosos podem resolver os problemas 2 e 3, deixando apenas 1, que pode ser resolvido adicionando um super() . Com esses dois recursos no lugar, poderíamos obter algo como:

func (T ... interface{})try(T, err error) super {
   if err != nil { 
      super(err)
   }
  super(T...)
}

E então o resgate adiado não seria mais necessário. Esse benefício estaria disponível mesmo se nenhum genérico fosse adicionado ao Go.

Na verdade, essa ideia de um super() embutido é tão poderosa e interessante que eu poderia postar uma proposta para ela separadamente.

@beoran É bom ver que chegamos exatamente às mesmas restrições independentemente em relação à implementação de try() no userland, exceto pela super parte que não incluí porque queria falar sobre algo semelhante em uma proposta alternativa. :-)

Eu gosto da proposta, mas o fato de você ter que especificar explicitamente que defer try(...) e go try(...) não são permitidos me fez pensar que algo não estava certo... A ortogonalidade é um bom guia de design. Ao ler mais e ver coisas como
x = try(foo(...)) y = try(bar(...))
Gostaria de saber se pode ser try precisa ser um contexto ! Considerar:
try ( x = foo(...) y = bar(...) )
Aqui foo() e bar() retornam dois valores, sendo o segundo error . A semântica de tentativa só importa para chamadas dentro do bloco try onde o valor de erro retornado é elidido (sem receptor) em vez de ignorado (o receptor é _ ). Você pode até mesmo lidar com alguns erros entre as chamadas foo e bar .

Resumo:
a) o problema de não permitir try para go e defer desaparece em virtude da sintaxe.
b) o tratamento de erros de várias funções pode ser fatorado.
c) sua natureza mágica é melhor expressa como sintaxe especial do que como chamada de função.

Se try for um contexto, acabamos de criar blocos try/catch que estamos tentando evitar especificamente (e por boas razões)

Não há captura. Exatamente o mesmo código seria gerado quando a proposta atual foi
x = try(foo(...)) y = try(bar(...))
Esta é apenas uma sintaxe diferente, não semântica.
````

Acho que fiz algumas suposições sobre isso que não deveria ter feito, embora ainda haja algumas desvantagens.

E se foo ou bar não retornarem um erro, eles também podem ser colocados no contexto try? Caso contrário, parece que seria meio feio alternar entre funções de erro e não-erro, e se puderem, voltamos aos problemas dos blocos try em linguagens mais antigas.

A segunda coisa é que normalmente a sintaxe keyword ( ... ) significa que você prefixa a palavra-chave em cada linha. Então, para import, var, const, etc: cada linha começa com a palavra-chave. Abrir uma exceção a essa regra não parece uma boa decisão

Ao invés de usar uma função, seria apenas mais idiomático usar um identificador especial?

Já temos o identificador em branco _ que ignora valores.
Poderíamos ter algo como # que só pode ser usado em funções que tenham o último valor retornado do tipo erro.

func foo() (error) {
    f, # := os.Open()
    defer f.Close()
    _, # = f.WriteString("foo")
    return nil
}

quando um erro é atribuído a # a função retorna imediatamente com o erro recebido. Já para as outras variáveis ​​seus valores seriam:

• se eles não forem nomeados valor zero
• o valor atribuído às variáveis ​​nomeadas caso contrário

@deanveloper , a semântica do bloco try importa apenas para funções que retornam um valor de erro e onde o valor de erro não é atribuído. Assim, o último exemplo da presente proposta também poderia ser escrito como
try(x = foo(...)) try(y = bar(...))
colocar ambas as instruções dentro do mesmo bloco é semelhante ao que fazemos para instruções repetidas import , const e var .

Agora se você tem, por exemplo
try( x = foo(...)) go zee(...) defer fum() y = bar(...) )
Isso é equivalente a escrever
try(x = foo(...)) go zee(...) defer fum() try(y = bar(...))
Fatorar tudo isso em um bloco try o torna menos ocupado.

Considerar
try(x = foo())
Se foo() não retornar um valor de erro, isso é equivalente a
x = foo()

Considerar
try(f, _ := os.open(filename))
Como o valor de erro retornado é ignorado, isso é equivalente a apenas
f, _ := os.open(filename)

Considerar
try(f, err := os.open(filename))
Como o valor de erro retornado não é ignorado, isso é equivalente a
f, err := os.open(filename) if err != nil { return ..., err }
Conforme especificado atualmente na proposta.

E também organiza muito bem as tentativas aninhadas!

Aqui está um link para a proposta alternativa que mencionei acima:

• https://github.com/golang/go/issues/32473

Ele exige a adição de dois (2) recursos de linguagem pequenos, mas de uso geral, para abordar os mesmos casos de uso que try()

1. Capacidade de chamar um func /closure em uma declaração de atribuição.
2. Capacidade de break , continue ou return mais de um nível.

Com esses dois recursos, eles não seriam _"mágicos"_ e acredito que seu uso produziria um código Go mais fácil de entender e mais alinhado com o código Go idiomático com o qual todos estamos familiarizados.

Eu li a proposta e realmente gosto de onde tentar está indo.

Dado o quão prevalente a tentativa será, eu me pergunto se torná-lo um comportamento mais padrão tornaria mais fácil de manusear.

Considere mapas. Isso é válido:

v := m[key]

como é este:

v, ok := m[key]

E se tratarmos os erros exatamente da maneira que o try sugere, mas removermos o builtin. Então, se começamos com:

v, err := fn()

Em vez de escrever:

v := try(fn())

Em vez disso, poderíamos escrever:

v := fn()

Quando o valor err não é capturado, ele é tratado exatamente como o try. Levaria um pouco para se acostumar, mas parece muito semelhante a v, ok := m[key] e v, ok := x.(string) . Basicamente, qualquer erro não tratado faz com que a função retorne e o valor de erro seja definido.

Para voltar às conclusões dos documentos de design e requisitos de implementação:

• A sintaxe do idioma é mantida e nenhuma palavra-chave nova é introduzida
• Continua a ser açúcar sintático como tentar e espero que seja fácil de explicar.
• Não requer nova sintaxe
• Deve ser totalmente compatível com versões anteriores.

Imagino que isso teria quase os mesmos requisitos de implementação que try, pois a principal diferença é, em vez do builtin disparar o açúcar sintático, agora é a ausência do campo err.

Então, usando o exemplo CopyFile da proposta junto com defer fmt.HandleErrorf(&err, "copy %s %s", src, dst) , obtemos:

func CopyFile(src, dst string) (err error) {
        defer fmt.HandleErrorf(&err, "copy %s %s", src, dst)

        r := os.Open(src)
        defer r.Close()

        w := os.Create(dst)
        defer func() {
                err := w.Close()
                if err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        io.Copy(w, r)
        w.Close()
        return nil
}

@savaki Eu gosto disso e estava pensando no que seria necessário para fazer o Go inverter o tratamento de erros sempre manipulando erros por padrão e deixar o programador especificar quando não fazer isso (capturando o erro em uma variável), mas total falta de qualquer identificador tornaria o código difícil de seguir, pois não seria possível ver todos os pontos de retorno. Pode ser uma convenção para nomear funções que poderiam retornar um erro de forma diferente poderia funcionar (como capitalizar identificadores públicos). Pode ser que se uma função retornou um erro, ela deve sempre terminar com, digamos ? . Então Go pode sempre tratar o erro implicitamente e retorná-lo automaticamente para a função de chamada assim como try. Isso o torna muito semelhante a algumas propostas sugerindo usar um identificador ? em vez de tentar, mas uma diferença importante é que aqui ? seria parte do nome da função e não um identificador adicional. Na verdade, uma função que retornou error como o último valor de retorno nem compilaria se não tivesse o sufixo ? . Claro que ? é arbitrário e pode ser substituído por qualquer outra coisa que torne a intenção mais explícita. operation?() seria equivalente a envolver try(someFunc()) mas ? faria parte do nome da função e seu único propósito seria indicar que a função pode retornar um erro assim como a capitalização a primeira letra de uma variável.

Isso superficialmente acaba sendo muito semelhante a outras propostas que pedem para substituir try por ? mas uma diferença crítica é que torna o tratamento de erros implícito (automático) e, em vez disso, torna explícito ignorar (ou encapsular) erros que uma espécie de melhor prática de qualquer maneira. O problema mais óbvio com isso, é claro, é que não é compatível com versões anteriores e tenho certeza de que há muitos mais.

Dito isso, eu estaria muito interessado em ver como o Go pode fazer o tratamento de erros do caso padrão/implícito automatizando-o e deixando o programador escrever um pouco de código extra para ignorar/substituir o tratamento. O desafio que eu acho é como tornar todos os pontos de retorno óbvios neste caso, porque sem isso os erros se tornarão mais como exceções no sentido de que eles podem vir de qualquer lugar, pois o fluxo do programa não o tornaria óbvio. Pode-se dizer que cometer erros implícitos com o indicador visual é o mesmo que implementar try e tornar errcheck uma falha do compilador.

poderíamos fazer algo como exceções c++ com decoradores para funções antigas?

func some_old_test() (int, error){
    return 0, errors.New("err1")
}
func some_new_test() (int){
        if true {
             return 1
        }
    throw errors.New("err2")
}
func throw_res(int, e error) int {
    if e != nil {
        throw e
    }
    return int
}
func main() {
    fmt.Println("Hello, playground")
    try{
        i := throw_res(some_old_test())
        fmt.Println("i=", i + some_new_test())
    } catch(err io.Error) {
        return err
    } catch(err error) {
        fmt.Println("unknown err", err)
    }
}

@owais Eu estava pensando que a semântica seria exatamente a mesma que tentar, então pelo menos você precisaria declarar o tipo de erro. Então, se começamos com:

func foo() error {
  _, err := fn() 
  if err != nil {
    return err
  }

  return nil
} 

Se eu entendi a proposta try, basta fazer isso:

func foo() error {
  _  := fn() 
  return nil
} 

não compilaria. Uma boa vantagem é que dá à compilação a oportunidade de dizer ao usuário o que está faltando. Algo no sentido de que o uso de tratamento de erros implícito requer que o tipo de retorno de erro seja nomeado, err.

Isso, então, funcionaria:

func foo() (err error) {
  _  := fn() 
  return nil
} 

por que não apenas lidar com o caso de um erro que não é atribuído a uma variável.

• remova a necessidade de retornos nomeados, o compilador pode fazer isso sozinho.
• permite adicionar contexto.
• lida com o caso de uso comum.
• compatível com versões anteriores
• não interage estranhamente com defer, loops ou switches.

retorno implícito para o caso if err != nil, o compilador pode gerar o nome da variável local para retornos, se necessário, não pode ser acessado pelo programador.
pessoalmente, não gosto deste caso em particular do ponto de vista da legibilidade do código

f := os.Open("foo.txt")

prefere um retorno explícito, segue o código é mais lido do que o mantra escrito

f := os.Open("foo.txt") else return

Curiosamente, poderíamos aceitar as duas formas e fazer com que o gofmt adicionasse automaticamente o else return.

adicionando contexto, também nomeação local da variável. return se torna explícito porque queremos adicionar contexto.

f := os.Open("foo.txt") else err {
  return errors.Wrap(err, "some context")
}

adicionando contexto com vários valores de retorno

f := os.Open("foo.txt") else err {
  return i, j, errors.Wrap(err, "some context")
}

funções aninhadas requerem que as funções externas tratem todos os resultados na mesma ordem
menos o erro final.

bits := ioutil.ReadAll(os.Open("foo")) else err {
  // either error ends up here.
  return i, j, errors.Wrap(err, "some context")
}

compilador recusa a compilação devido ao valor de retorno de erro ausente na função

func foo(s string) int {
   i := strconv.Atoi(s) // cannot implicitly return error due to missing error return value for foo.
   return i * 2
}

compila alegremente porque o erro é explicitamente ignorado.

func foo(s string) int {
   i, _ := strconv.Atoi(s)
   return i * 2
} 

compilador está feliz. ele ignora o erro como faz atualmente porque não ocorre nenhuma atribuição ou sufixo.

func foo() error {
  return errors.New("whoops")
}

func bar() {
  foo()
}

dentro de um loop você pode usar continue.

for _, s := range []string{"1","2","3","4","5","6"} {
  i := strconv.Atoi(s) else continue
}

edit: substituiu ; por else

@savaki Acho que entendi seu comentário original e gosto da ideia de Go lidar com erros por padrão, mas não acho viável sem adicionar algumas alterações de sintaxe adicionais e, uma vez que fazemos isso, torna-se surpreendentemente semelhante à proposta atual.

A maior desvantagem do que você propõe é que ele não expõe todos os pontos de onde uma função pode retornar ao contrário do if err != nil {return err} atual ou da função try apresentada nesta proposta. Mesmo que funcionasse exatamente da mesma maneira sob o capô, visualmente o código seria muito diferente. Ao ler o código, não haveria como saber quais chamadas de função podem retornar um erro. Isso acabaria sendo uma experiência pior do que exceções IMO.

Pode ser que o tratamento de erros possa ser tornado implícito se o compilador forçar alguma convenção semântica em funções que possam retornar erros. Como eles devem começar ou terminar com uma determinada frase ou personagem. Isso tornaria todos os pontos de retorno muito óbvios e acho que seria melhor do que o tratamento manual de erros, mas não tenho certeza de quão significativamente melhor, considerando que já existem verificações de lint que exigem carga quando detectam um erro sendo ignorado. Seria muito interessante ver se o compilador pode forçar as funções a serem nomeadas de uma certa maneira dependendo se elas podem retornar possíveis erros.

A principal desvantagem dessa abordagem é que o parâmetro de resultado do erro precisa ser nomeado, possivelmente levando a APIs menos bonitas (mas veja as perguntas frequentes sobre esse assunto). Acreditamos que nos acostumaremos com isso uma vez que esse estilo se estabeleça.

Não tenho certeza se algo assim já foi sugerido antes, não consigo encontrar aqui ou na proposta. Você considerou outra função interna que retorna um ponteiro para o valor de retorno de erro da função atual?
por exemplo:

func example() error {
        var err *error = funcerror() // always return a non-nil pointer
        fmt.Print(*err) // always nil if the return parameters are not named and not in a defer

        defer func() {
                err := funcerror()
                fmt.Print(*err) // "x"
        }

        return errors.New("x")
}

func exampleNamed() (err error) {
        funcErr := funcerror()
        fmt.Print(*funcErr) // "nil"

        err = errors.New("x")
        fmt.Print(*funcErr) // "x", named return parameter is reflected even before return is called

        *funcErr = errors.New("y")
        fmt.Print(err) // "y", unfortunate side effect?

        defer func() {
                funcErr := funcerror()
                fmt.Print(*funcErr) // "z"
                fmt.Print(err) // "z"
        }

        return errors.New("z")
}

uso com try:

func CopyFile(src, dst string) (error) {
        defer func() {
                err := funcerror()
                if *err != nil {
                        *err = fmt.Errorf("copy %s %s: %v", src, dst, err)
                }
        }()
        // one liner alternative
        // defer fmt.HandleErrorf(funcerror(), "copy %s %s", src, dst)

        r := try(os.Open(src))
        defer r.Close()

        w := try(os.Create(dst))
        defer func() {
                w.Close()
                err := funcerror()
                if *err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        try(io.Copy(w, r))
        try(w.Close())
        return nil
}

Alternativamente funcerror (o nome é um trabalho em andamento :D ) pode retornar nil se não for chamado dentro de defer.

Outra alternativa é que funcerror retorne uma interface "Errorer" para torná-la somente leitura:

type interface Errorer() {
        Error() error
}

@savaki Na verdade, gosto da sua proposta de omitir try() e permitir que seja mais como testar um mapa ou uma declaração de tipo. Isso parece muito mais _"Go-like."_

No entanto, ainda há um problema gritante que vejo, e essa é a sua proposta presume que todos os erros usando essa abordagem acionarão um return e deixarão a função. O que não contempla é emitir um break do atual for ou um continue do atual for .

Os primeiros return s são uma marreta quando muitas vezes um bisturi é a melhor escolha.

Portanto, afirmo que break e continue devem ser estratégias válidas de tratamento de erros e, atualmente, sua proposta pressupõe apenas return enquanto try() presume isso ou chamar um erro handler que por si só pode return , não break ou continue .

Parece que o savaki e eu tivemos ideias semelhantes, apenas adicionei a semântica do bloco para lidar com o erro, se desejado. Por exemplo, adicionando comtexto, para loops onde você deseja curto-circuito, etc.

@mikeschinkel veja minha extensão, ele e eu tivemos ideias semelhantes, apenas a estendi com uma instrução de bloco opcional

@james-lawrence

@mikesckinkel veja minha extensão, ele e eu tivemos ideias semelhantes, apenas a estendi com uma instrução de bloco opcional

Tomando seu exemplo:

f := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

O que se compara ao que fazemos hoje:

f,err := os.Open("foo.txt"); 
if err != nil {
  return errors.Wrap(err, "some context")
}

É definitivamente preferível para mim. Exceto que tem alguns problemas:

1. err parece ser _"magicamente"_ declarado. A magia deve ser minimizada, não? Então vamos declarar:

f, err := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

1. Mas isso ainda não funciona porque Go não interpreta valores nil como false nem valores de ponteiro como true , então precisaria ser:

f, err := os.Open("foo.txt"); err != nil {
  return errors.Wrap(err, "some context")
}

E o que isso funciona, começa a parecer muito trabalho e muita sintaxe em uma linha, então e eu posso continuar a fazer o caminho antigo para maior clareza.

Mas e se o Go adicionasse dois (2) built-ins; iserror() e error() ? Então poderíamos fazer isso, o que não me parece tão ruim:

f := os.Open("foo.txt"); iserror() {
  return errors.Wrap(error(), "some context")
}

Ou melhor _(algo como):_

f := os.Open("foo.txt"); iserror() {
  return error().Extend("some context")
}

O que você e os outros pensam?

Como um aparte, verifique a ortografia do meu nome de usuário. Eu não teria sido notificado de sua menção se eu não estivesse prestando atenção de qualquer maneira ...

@mikeschinkel desculpe pelo nome que eu estava no meu telefone e o github não estava sugerindo automaticamente.

err parece ser declarado "magicamente". A magia deve ser minimizada, não? Então vamos declarar:

meh, toda a ideia de inserir automaticamente um retorno é mágica. esta não é a coisa mais mágica acontecendo em toda esta proposta. Além disso, eu argumentaria que o erro foi declarado; apenas no final, dentro do contexto de um bloco com escopo, evitando que ele polua o escopo pai enquanto ainda mantém todas as coisas boas que obtemos normalmente usando instruções if.

Em geral, estou muito feliz com o tratamento de erros do go com as próximas adições ao pacote de erros. Não vejo nada nesta proposta como super útil. Estou apenas tentando oferecer o ajuste mais natural para o golang se estivermos decididos a fazê-lo.

_"toda a ideia de inserir um retorno automaticamente é mágica."_

Você não terá nenhum argumento meu lá.

_"isso não é a coisa mais mágica acontecendo em toda esta proposta."_

Acho que estava tentando argumentar que _"toda magia é problemática."_

_"Além disso, eu diria que o erro foi declarado; apenas no final dentro do contexto de um bloco com escopo..."_

Então, se eu quisesse chamá-lo de err2 , isso também funcionaria?

f := os.Open("foo.txt"); err2 {
  return errors.Wrap(err, "some context")
}

Portanto, suponho que você também esteja propondo tratamento de caso especial do err / err2 após o ponto e vírgula, ou seja, que seria assumido nil ou não nil em vez de bool como ao verificar um mapa?

if _,ok := m[a]; !ok {
   print("there is no 'a' in 'm'")
}

Em geral, estou muito feliz com o tratamento de erros do go com as próximas adições ao pacote de erros.

Eu também estou feliz com o tratamento de erros, quando combinado com break e continue _(mas não return .)_

Do jeito que está, vejo essa proposta try() como mais prejudicial do que útil, e prefiro não ver nada do que esse implemento conforme proposto. #jmtcw.

@beoran @mikeschinkel Anteriormente, sugeri que não poderíamos implementar esta versão de try usando genéricos, porque isso altera o fluxo de controle. Se estou lendo corretamente, vocês dois estão sugerindo que podemos usar genéricos para implementar try fazendo com que ele chame panic . Mas esta versão de try muito explicitamente não panic . Portanto, não podemos usar genéricos para implementar esta versão de try .

Sim, poderíamos usar genéricos (uma versão de genéricos significativamente mais poderosa do que a do rascunho de design em https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md) para escrever uma função que entra em pânico no erro. Mas entrar em pânico com o erro não é o tipo de tratamento de erro que os programadores Go escrevem hoje, e não me parece uma boa ideia.

O tratamento especial do @mikeschinkel seria que o bloco executasse apenas quando ocorresse um erro.
```
f := os.Open('foo'); err { return err } // err sempre seria não nulo aqui.

@ianlancetaylor

_"Sim, poderíamos usar genéricos... Mas entrar em pânico com o erro não é o tipo de tratamento de erro que os programadores Go escrevem hoje, e não me parece uma boa ideia."_

Na verdade, concordo fortemente com você sobre isso, portanto, parece que você pode ter interpretado mal a intenção do meu comentário. Eu não estava sugerindo que a equipe Go implementaria o tratamento de erros que usava panic() — claro que não.

Em vez disso, eu estava tentando realmente seguir sua liderança de muitos de seus comentários anteriores sobre outras questões e sugeri que evitássemos fazer quaisquer alterações no Go que não fossem absolutamente necessárias, porque elas são possíveis no userland . Então _se_ os genéricos foram endereçados _então_ as pessoas que gostariam try() poderiam de fato implementá-lo por conta própria, embora alavancando panic() . E esse seria um recurso a menos que a equipe precisaria adicionar e documentar para Go.

O que eu não estava fazendo - e talvez isso não estivesse claro - era defender que as pessoas realmente usassem panic() para implementar try() , apenas que poderiam se realmente quisessem, e tivessem os recursos de genéricos.

Isso esclarece?

Para mim, chamar panic , seja como for, é bem diferente desta proposta para try . Então, embora eu ache que entendo o que você está dizendo, não concordo que sejam equivalentes. Mesmo que tivéssemos genéricos poderosos o suficiente para implementar uma versão de try que entre em pânico, acho que ainda haveria um desejo razoável pela versão de try apresentada nesta proposta.

@ianlancetaylor Reconhecido. Novamente, eu estava procurando um motivo pelo qual try() não precisasse ser adicionado em vez de encontrar uma maneira de adicioná-lo. Como eu disse acima, eu prefiro não ter nada de novo para tratamento de erros do que ter try() como proposto aqui.

Eu pessoalmente gostei mais da proposta check anterior, baseada em aspectos puramente visuais; check tinha o mesmo poder que este try() mas bar(check foo()) é mais legível para mim do que bar(try(foo())) (eu só precisava de um segundo para contar os parênteses!).

Mais importante, minha principal reclamação sobre handle / check era que ele não permitia empacotar cheques individuais de maneiras diferentes - e agora essa proposta try() tem a mesma falha, enquanto invoca recursos complicados e confusos para novatos de adiamentos e retornos nomeados. E com handle pelo menos tivemos a opção de usar escopos para definir blocos handle, com defer nem isso é possível.

No que me diz respeito, esta proposta perde para a proposta anterior handle / check em todos os aspectos.

Aqui está outra preocupação com o uso de adiamentos para tratamento de erros.

try é uma saída controlada/intencional de uma função. adias são executados sempre, incluindo saídas não controladas/não intencionais das funções. Essa incompatibilidade pode causar confusão. Aqui está um cenário imaginário:

func someHTTPHandlerGuts() (err error) {
  defer func() {
    recordMetric("db call failed")
    return fmt.HandleErrorf("db unavailable: %v", err)
  }()
  data := try(makeDBCall)
  // some code that panics due to a bug
  return nil
}

Lembre-se de que net/http se recupera de panics e imagine depurar um problema de produção em torno do panic. Você olharia para sua instrumentação e veria um pico nas falhas de chamadas de banco de dados, das chamadas recordMetric . Isso pode mascarar o verdadeiro problema, que é o pânico na linha subsequente.

Não tenho certeza de quão séria é essa preocupação na prática, mas é (infelizmente) talvez outra razão para pensar que adiar não é um mecanismo ideal para tratamento de erros.

Aqui está uma modificação que pode ajudar com algumas das preocupações levantadas: Trate try como goto ao invés de return . Me ouça. :)

try seria açúcar sintático para:

t1, … tn, te := f()  // t1, … tn, te are local (invisible) temporaries
if te != nil {
        err = te   // assign te to the error result parameter
        goto error // goto "error" label
}
x1, … xn = t1, … tn  // assignment only if there was no error

Benefícios:

• defer não é necessário para decorar erros. (No entanto, os retornos nomeados ainda são necessários.)
• A existência do rótulo error: é uma pista visual de que existe um try em algum lugar da função.

Isso também fornece um mecanismo para adicionar manipuladores que evitam os problemas do manipulador como função: Use rótulos como manipuladores. try(fn(), wrap) seria goto wrap em vez de goto error . O compilador pode confirmar que wrap: está presente na função. Observe que ter manipuladores também ajuda na depuração: você pode adicionar/alterar o manipulador para fornecer um caminho de depuração.

Código de amostra:

func CopyFile(src, dst string) (err error) {
    r := try(os.Open(src))
    defer r.Close()

    w := try(os.Create(dst))
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “try” fails
        }
    }()

    try(io.Copy(w, r), copyfail)
    try(w.Close())
    return nil

error:
    return fmt.Errorf("copy %s %s: %v", src, dst, err)

copyfail:
    recordMetric("copy failure") // count incidents of this failure
    return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

Outros comentários:

• Podemos exigir que qualquer rótulo usado como destino de um try seja precedido por uma instrução final. Na prática, isso os forçaria ao fim da função e poderia impedir algum código de espaguete. Por outro lado, pode impedir alguns usos razoáveis ​​e úteis.
• try pode ser usado para criar um loop. Acho que isso se enquadra na bandeira de "se dói, não faça", mas não tenho certeza.
• Isso exigiria a correção de https://github.com/golang/go/issues/26058.

Crédito: acredito que uma variante dessa ideia foi sugerida pela primeira vez por @griesemer pessoalmente na GopherCon no ano passado.

@josharian Pensar sobre a interação com panic é importante aqui, e fico feliz que você tenha mencionado isso, mas seu exemplo me parece estranho. No código a seguir, não faz sentido para mim que o defer sempre registre uma métrica "db call failed" . Seria uma métrica falsa se someHTTPHandlerGuts obtiver sucesso e retornar nil . O defer é executado em todos os casos de saída, não apenas em casos de erro ou pânico, então o código parece errado mesmo que não haja pânico.

func someHTTPHandlerGuts() (err error) {
  defer func() {
    recordMetric("db call failed")
    return fmt.HandleErrorf("db unavailable: %v", err)
  }()
  data := try(makeDBCall)
  // some code that panics due to a bug
  return nil
}

@josharian Sim, esta é mais ou menos exatamente a versão que discutimos no ano passado (exceto que usamos check em vez de try ). Eu acho que seria crucial que não se pudesse pular "de volta" para o resto do corpo da função, uma vez que estamos no rótulo error . Isso garantiria que o goto fosse um pouco "estruturado" (sem código de espaguete possível). Uma preocupação que foi levantada foi que o rótulo do manipulador de erros (o error: ) sempre terminaria no final da função (caso contrário, seria necessário pular de alguma forma). Pessoalmente, eu gosto do código de tratamento de erros fora do caminho (no final), mas outros acharam que ele deveria estar visível logo no início.

@mikeshenkel eu vejo o retorno de um loop como um sinal positivo em vez de negativo. Meu palpite é que isso encorajaria os desenvolvedores a usar uma função separada para lidar com o conteúdo de um loop ou usar explicitamente err como fazemos atualmente. Ambos parecem bons resultados para mim.

Do meu ponto de vista, não sinto que essa sintaxe try tenha que lidar com todos os casos de uso, assim como não sinto que preciso usar o

V, ok:= m[chave]

Formulário da leitura de um mapa

Você pode evitar que os rótulos goto forcem os manipuladores para o final da função ressuscitando a proposta handle / check de uma forma simplificada. E se usássemos a sintaxe handle err { ... } mas não deixássemos os manipuladores encadearem, em vez disso, apenas o último fosse usado. Ele simplifica muito essa proposta, e é muito parecido com a ideia goto, exceto que coloca o manuseio mais próximo do ponto de uso.

func CopyFile(src, dst string) (err error) {
    handle err {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    r := check os.Open(src)
    defer r.Close()

    w := check os.Create(dst)
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “check” fails
        }
    }()

    {
        // handlers are scoped, after this scope the original handle is used again.
        // as an alternative, we could have repeated the first handle after the io.Copy,
        // or come up with a syntax to name the handlers, though that's often not useful.
        handle err {
            recordMetric("copy failure") // count incidents of this failure
            return fmt.Errorf("copy %s %s: %v", src, dst, err)
        }
        check io.Copy(w, r)
    }
    check w.Close()
    return nil
}

Como bônus, isso tem um caminho futuro para permitir que os manipuladores encadeem, pois todos os usos existentes teriam um retorno.

@josharian @griesemer se você introduzir manipuladores nomeados (que muitas respostas para verificar/tratar solicitadas, veja temas recorrentes ), existem opções de sintaxe preferíveis a try(f(), err) :

try.err f()
try?err f()
try#err f()

?err    f() // because 'try' is redundant
?return f() // no handler
?panic  f() // no handler

(?err f()).method()

f?err() // lead with function name, instead of error handling
f?err().method()

file, ?err := os.Open(...) // many check/handle responses also requested this style

Uma das coisas que mais gosto no Go é que sua sintaxe é relativamente livre de pontuação e pode ser lida em voz alta sem grandes problemas. Eu realmente odiaria que Go acabasse como $#@!perl .

Para mim, fazer "experimentar" uma função interna e habilitar cadeias tem 2 problemas:

• É inconsistente com o restante do fluxo de controle em go (por exemplo, palavras-chave for/if/return/etc).
• Isso torna o código menos legível.

Eu preferiria fazer uma declaração sem parênteses. Os exemplos na proposta exigiriam várias linhas, mas se tornariam mais legíveis (ou seja, instâncias individuais de "experimentar" seriam mais difíceis de perder). Sim, isso quebraria os analisadores externos, mas prefiro preservar a consistência.

O operador ternário é outro lugar onde ir não tem algo e requer mais teclas, mas ao mesmo tempo melhora a legibilidade/manutenção. Adicionar "tentar" nesta forma mais restrita equilibrará melhor expressividade versus legibilidade, IMO.

FWIW, panic afeta o fluxo de controle e tem parênteses, mas go e defer também afetam o fluxo e não. Eu costumo pensar que try é mais parecido com defer porque é uma operação de fluxo incomum e dificultar a execução de try (try os.Open(file)).Read(buf) é bom porque queremos desencorajar one-liners enfim, mas tanto faz. Qualquer um serve.

Sugestão que todos vão odiar por um nome implícito para uma variável de retorno de erro final: $err . É melhor do que try() IMO. :-)

@griesemer

_"Pessoalmente, eu gosto do código de tratamento de erros fora do caminho (no final)"_

+1 para isso!

Acho que o tratamento de erros implementado _antes_ do erro ocorrer é muito mais difícil de raciocinar do que o tratamento de erros implementado _depois_ do erro ocorrer. Ter que pular mentalmente para trás e forçar a seguir o fluxo lógico parece que estou de volta a 1980 escrevendo Basic com GOTOs.

Deixe-me propor outra maneira potencial de lidar com erros usando CopyFile() como exemplo novamente:

func CopyFile(src, dst string) (err error) {

    r := os.Open(src)
    defer r.Close()

    w := os.Create(dst)
    defer w.Close()

    io.Copy(w, r)
    w.Close()

    for err := error {
        switch err.Source() {
        case w.Close:
            os.Remove(dst) // only if a “try” fails
            fallthrough
        case os.Open, os.Create, io.Copy:
            err = fmt.Errorf("copy %s %s: %v", src, dst, err)
        default:
            err = fmt.Errorf("an unexpected error occurred")
        }
    }

    return err
}

As alterações de idioma necessárias seriam:

1. Permite uma construção for error{} , semelhante a for range{} mas apenas inserida em caso de erro e executada apenas uma vez.

2. Permite omitir a captura de valores de retorno que implementam <object>.Error() string mas somente quando existe uma construção for error{} dentro do mesmo func .

3. Faça com que o fluxo de controle do programa salte para a primeira linha da construção for error{} quando um func retornar um _"error"_ em seu último valor de retorno.

4. Ao retornar um _"erro"_ Go adicionaria atribuir uma referência à função que retornou o erro que deve ser recuperável por <error>.Source()

O que é um _"erro"_?

Atualmente um _"error"_ é definido como qualquer objeto que implementa Error() string e, claro, não é nil .

No entanto, muitas vezes há a necessidade de estender o erro _mesmo em caso de sucesso_ para permitir o retorno de valores necessários para resultados de sucesso de uma API RESTful. Portanto, peço que a equipe Go não assuma automaticamente que err!=nil significa _"erro"_, mas verifique se um objeto de erro implementa um IsError() e se IsError() retorna true antes de assumir que qualquer valor diferente nil é um _"erro."_

_(Não estou necessariamente falando de código na biblioteca padrão, mas principalmente se você escolher seu fluxo de controle para ramificar em um _"erro"_. Se você olhar apenas para err!=nil , ficaremos muito limitados no que pode fazer em termos de valores de retorno em nossas funções.)_

BTW, permitir que todos testem um _"erro"_ da mesma maneira provavelmente poderia ser feito mais facilmente adicionando uma nova função interna iserror() :

type ErrorIser interface {
    IsError() bool
}
func iserror(err error) bool {
    if err == nil { 
        return false
    }
    if _,ok := err.(ErrorIser); !ok {
        return true
    }
    return err.IsError()
}

Um benefício colateral de permitir a não captura de _"erros"_

Observe que permitir a não captura do último _"error"_ de chamadas func permitiria a refatoração posterior para retornar erros de func s que inicialmente não precisavam retornar erros. E isso permitiria essa refatoração sem quebrar nenhum código existente que usa essa forma de recuperação de erros e chama os ditos func s.

Para mim, essa decisão de _"Devo retornar um erro ou renunciar ao tratamento de erros para chamar a simplicidade?"_ é um dos meus maiores dilemas ao escrever código Go. Permitir a não captura de _"erros"_ acima eliminaria esse dilema.

Na verdade, tentei implementar essa ideia como tradutor Go cerca de meio ano atrás. Não tenho uma opinião forte se esse recurso deve ser adicionado como Go embutido, mas deixe-me compartilhar a experiência (embora não tenha certeza de que seja útil).

https://github.com/rhysd/trygo

Chamei a linguagem estendida de TryGo e implementei o tradutor TryGo to Go.

Com o tradutor, o código

func CreateFileInSubdir(subdir, filename string, content []byte) error {
    cwd := try(os.Getwd())

    try(os.Mkdir(filepath.Join(cwd, subdir)))

    p := filepath.Join(cwd, subdir, filename)
    f := try(os.Create(p))
    defer f.Close()

    try(f.Write(content))

    fmt.Println("Created:", p)
    return nil
}

pode ser traduzido em

func CreateFileInSubdir(subdir, filename string, content []byte) error {
    cwd, _err0 := os.Getwd()
    if _err0 != nil {
        return _err0
    }

    if _err1 := os.Mkdir(filepath.Join(cwd, subdir)); _err1 != nil {
        return _err1
    }

    p := filepath.Join(cwd, subdir, filename)
    f, _err2 := os.Create(p)
    if _err2 != nil {
        return _err2
    }
    defer f.Close()

    if _, _err3 := f.Write(content); _err3 != nil {
        return _err3
    }

    fmt.Println("Created:", p)
    return nil
}

Pela restrição de idioma, não consegui implementar a chamada genérica try() . É restrito a

• RHS da declaração de definição
• RHS da declaração de atribuição
• Extrato de chamada

mas eu poderia tentar isso com meu pequeno projeto. Minha experiência foi

• basicamente funciona bem e salva várias linhas
• o valor de retorno nomeado é realmente inutilizável para err pois o valor de retorno de sua função é determinado pela atribuição e pela função especial try() . muito confuso
• esta função try() não tinha o recurso 'erro de encapsulamento' conforme discutido acima.

_"Ambos parecem bons resultados para mim."_

Teremos que concordar em discordar aqui.

_"esta sintaxe try (não precisa) lidar com todos os casos de uso"_

Esse meme é provavelmente o mais preocupante. Pelo menos considerando a resistência da equipe/comunidade Go a quaisquer mudanças no passado que não sejam amplamente aplicáveis.

Se permitirmos essa justificativa aqui, por que não podemos revisitar propostas anteriores que foram rejeitadas porque não eram amplamente aplicáveis?

E agora estamos abertos para argumentar por mudanças no Go que são úteis apenas para casos extremos selecionados?

Na minha opinião, estabelecer este precedente não produzirá bons resultados a longo prazo...

_"@mikeshenkel"_

PS Eu não vi sua mensagem no início por causa de um erro de ortografia. _(isso não me ofende, só não sou notificado quando meu nome de usuário é digitado incorretamente...)_

Eu aprecio o compromisso com a compatibilidade com versões anteriores que motiva você a tornar try um builtin, em vez de uma palavra-chave, mas depois de lutar com a _estranheza_ total de ter uma função usada com frequência que pode alterar o fluxo de controle ( panic e recover são extremamente raros), fiquei me perguntando: alguém fez alguma análise em larga escala da frequência de try como identificador em bases de código de código aberto? Eu estava curioso e cético, então fiz uma pesquisa preliminar no seguinte:

• https://github.com/google/go-github
• https://github.com/cockroachdb/cockroach
• https://github.com/golang/net
• https://github.com/exercism/xgo
• https://github.com/GoogleCloudPlatform/kubernetes
• https://github.com/syncthing/syncthing
• https://github.com/mitchellh/packer
• https://github.com/drone/drone
• https://github.com/coreos/etcd
• https://github.com/docker/docker
• https://github.com/sjwhitworth/golearn
• https://github.com/bitly/nsq
• https://github.com/smartystreets/goconvey
• https://github.com/golang/tools
• https://github.com/coreos/fleet
• https://github.com/limetext/lime
• https://github.com/flynn/flynn
• https://github.com/dropbox/godropbox
• https://github.com/hashicorp/consul
• https://github.com/hashicorp/terraform

Nas 11.108.770 linhas significativas de Go que vivem nesses repositórios, havia apenas 63 instâncias de try sendo usadas como identificador. Claro, eu percebo que essas bases de código (embora grandes, amplamente usadas e importantes por si só) representam apenas uma fração do código Go lá fora e, além disso, não temos como analisar diretamente as bases de código privadas, mas certamente é um resultado interessante.

Além disso, como try , como qualquer palavra-chave, é minúscula, você nunca a encontrará na API pública de um pacote. As adições de palavras-chave afetarão apenas as partes internas do pacote.

Isso tudo é o prefácio de algumas ideias que eu queria colocar no mix que se beneficiariam de try como palavra-chave.

Eu proporia as seguintes construções.

1) Sem manipulador

// The existing proposal, but as a keyword rather than builtin.  When an error is 
// "caught", the function returns all zero values plus the error.  Nothing 
// particularly new here.
func doSomething() (int, error) {
    try SomeFunc()
    a, b := try AnotherFunc()

    // ...

    return 123, nil
}

2) Manipulador

Observe que os manipuladores de erros são blocos de código simples, destinados a serem embutidos, em vez de funções. Mais sobre isso abaixo.

func doSomething() (int, error) {
    // Inline error handler
    a, b := try SomeFunc() else err {
        return 0, errors.Wrap(err, "error in doSomething:")
    }

    // Named error handlers
    handler logAndContinue err {
        log.Errorf("non-critical error: %v", err)
    }
    handler annotateAndReturn err {
        return 0, errors.Wrap(err, "error in doSomething:")
    }

    c, d := try SomeFunc() else logAndContinue
    e, f := try OtherFunc() else annotateAndReturn

    // ...

    return 123, nil
}

Restrições propostas:

• Você só pode try uma chamada de função. Não try err .
• Se você não especificar um manipulador, poderá apenas try de dentro de uma função que retorne um erro como seu valor de retorno mais à direita. Não há mudança em como try se comporta com base em seu contexto. Ele nunca entra em pânico (como discutido muito anteriormente no tópico).
• Não existe nenhuma "cadeia de manipuladores" de qualquer tipo. Os manipuladores são apenas blocos de código inlineáveis.

Benefícios:

• A sintaxe try / else poderia ser trivialmente desaçucarada no "composto if" existente:
  go a, b := try SomeFunc() else err { return 0, errors.Wrap(err, "error in doSomething:") }
  torna-se
  go if a, b, err := SomeFunc(); err != nil { return 0, errors.Wrap(err, "error in doSomething:") }
  A meu ver, ifs compostos sempre pareceram mais confusos do que úteis por uma razão muito simples: condicionais geralmente ocorrem _depois_ de uma operação e têm algo a ver com o processamento de seus resultados. Se a operação estiver inserida dentro da instrução condicional, é simplesmente menos óbvio que está acontecendo. O olho está distraído. Além disso, o escopo das variáveis ​​definidas não é tão óbvio quanto quando elas estão mais à esquerda em uma linha.
• Os manipuladores de erros não são intencionalmente definidos como funções (nem com nada que se assemelhe à semântica de função). Isso faz várias coisas para nós:
  
  
  
  • O compilador pode simplesmente inline um manipulador nomeado onde quer que seja referido. É muito mais como um modelo simples de macro/codegen do que uma chamada de função. O tempo de execução nem precisa saber que existem manipuladores.
  
  
  • Não estamos limitados em relação ao que podemos fazer dentro de um manipulador. Contornamos a crítica de check / handle que "essa estrutura de tratamento de erros é boa apenas para resgates". Também contornamos a crítica da "cadeia de manipuladores". Qualquer código arbitrário pode ser colocado dentro de um desses manipuladores e nenhum outro fluxo de controle está implícito.
  
  
  • Não precisamos sequestrar return dentro do manipulador para significar super return . Seqüestrar uma palavra-chave é extremamente confuso. return significa apenas return , e não há necessidade real de super return .
  
  
  • defer não precisa trabalhar como um mecanismo de tratamento de erros. Podemos continuar a pensar nisso principalmente como uma forma de limpar recursos, etc.
  
  
• Sobre adicionar contexto aos erros:
  
  
  
  • Adicionar contexto com manipuladores é extremamente simples e se parece muito com os blocos if err != nil existentes
  
  
  • Mesmo que a construção "tente sem manipulador" não encoraje diretamente a adição de contexto, é muito simples refatorar no formulário do manipulador. Seu uso pretendido seria principalmente durante o desenvolvimento, e seria extremamente simples escrever uma verificação de go vet para destacar erros não tratados.
  
  

Desculpe se essas ideias são muito parecidas com outras propostas — tentei acompanhar todas elas, mas posso ter perdido um bom negócio.

@brynbellomy Obrigado pela análise de palavras-chave - é uma informação muito útil. Parece que try como palavra-chave pode estar ok. (Você diz que as APIs não são afetadas - isso é verdade, mas try ainda pode aparecer como nome de parâmetro ou algo parecido - então a documentação pode ter que mudar. Mas eu concordo que isso não afetaria os clientes desses pacotes.)

Em relação à sua proposta: ficaria muito bem mesmo sem manipuladores nomeados, não é? (Isso simplificaria a proposta sem perda de energia. Pode-se simplesmente chamar uma função local do manipulador embutido.)

Em relação à sua proposta: ficaria muito bem mesmo sem manipuladores nomeados, não é? (Isso simplificaria a proposta sem perda de energia. Pode-se simplesmente chamar uma função local do manipulador embutido.)

@griesemer De fato - eu estava me sentindo bastante morno em incluir isso. Certamente mais Go-ish sem.

Por outro lado, parece que as pessoas querem a capacidade de fazer tratamento de erros de uma linha, incluindo frases que return . Um caso típico seria log, então return . Se desembolsar para uma função local na cláusula else , provavelmente perderemos isso:

a, b := try SomeFunc() else err {
    someLocalFunc(err)
    return 0, err
}

(Eu ainda prefiro isso a ifs compostos, no entanto)

No entanto, você ainda pode obter retornos de uma linha que adicionam contexto de erro implementando um simples ajuste gofmt discutido anteriormente no tópico:

a, b := try SomeFunc() else err { return 0, errors.Wrap(err, "bad stuff!") }

A nova palavra-chave é necessária na proposta acima? Por que não:

SomeFunc() else return
a, b := SomeOtherFunc() else err { return 0, errors.Wrap(err, "bad stuff!") }

@griesemer se os manipuladores estiverem de volta à mesa, sugiro que você crie um novo problema para discussão de try/handle ou try/_label_. Essa proposta omitiu especificamente os manipuladores e existem inúmeras maneiras de defini-los e invocá-los.

Qualquer pessoa que sugira manipuladores deve primeiro ler o wiki de feedback de verificação/manuseio. As chances são boas de que o que você sonha já está descrito lá :-)
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback

@smonkewitz não, uma nova palavra-chave não é necessária nessa versão, pois está vinculada a instruções de atribuição, que foram mencionadas várias vezes até agora em vários açúcares de sintaxe.

https://github.com/golang/go/issues/32437#issuecomment -499808741
https://github.com/golang/go/issues/32437#issuecomment -499852124
https://github.com/golang/go/issues/32437#issuecomment -500095505

@ianlancetaylor esse tipo específico de tratamento de erros já foi considerado pela equipe go? Não é tão fácil de implementar quanto o try proposto, mas parece mais idiomático. ~declaração desnecessária, desculpe.~

Gostaria de repetir algo que @deanveloper e alguns outros disseram, mas com minha própria ênfase. Em https://github.com/golang/go/issues/32437#issuecomment -498939499 @deanveloper disse:

try é um retorno condicional. O fluxo de controle E os retornos são mantidos em pedestais em Go. Todo o fluxo de controle dentro de uma função é recuado e todos os retornos começam com return . Misturar esses dois conceitos em uma chamada de função fácil de perder parece um pouco estranho.

Além disso, nesta proposta try é uma função que retorna valores, portanto pode ser usada como parte de uma expressão maior.

Alguns argumentaram que panic já estabeleceu o precedente para uma função incorporada que altera o fluxo de controle, mas acho que panic é fundamentalmente diferente por dois motivos:

1. O pânico não é condicional; ele sempre aborta a função de chamada.
2. Panic não retorna nenhum valor e, portanto, só pode aparecer como uma declaração independente, o que aumenta sua visibilidade.

Tente por outro lado:

1. É condicional; ele pode ou não retornar da função de chamada.
2. Retorna valores e pode aparecer em uma expressão composta, possivelmente várias vezes, em uma única linha, potencialmente além da margem direita da minha janela do editor.

Por essas razões, acho que try parece mais do que um "pouco fora", acho que prejudica fundamentalmente a legibilidade do código.

Hoje, quando encontramos algum código Go pela primeira vez, podemos vasculhá-lo rapidamente para encontrar os possíveis pontos de saída e controlar os pontos de fluxo. Eu acredito que é uma propriedade altamente valiosa do código Go. Usando try fica muito fácil escrever código sem essa propriedade.

Admito que é provável que os desenvolvedores de Go que valorizam a legibilidade do código convergiriam em idiomas de uso para try que evitam essas armadilhas de legibilidade. Espero que isso aconteça, pois a legibilidade do código parece ser um valor fundamental para muitos desenvolvedores de Go. Mas não é óbvio para mim que try agrega valor suficiente sobre os idiomas de código existentes para carregar o peso de adicionar um novo conceito à linguagem para que todos aprendam e isso pode facilmente prejudicar a legibilidade.

````
se != "quebrou" {
não conserte (isso)
}

@ChrisHines Para o seu ponto (que é repetido em outro lugar neste tópico), vamos adicionar outra restrição:

• qualquer instrução try (mesmo aquelas sem um manipulador) deve ocorrer em sua própria linha.

Você ainda se beneficiaria de uma grande redução no ruído visual. Então, você tem retornos garantidos anotados por return e retornos condicionais anotados por try , e essas palavras-chave sempre ficam no início de uma linha (ou na pior das hipóteses, diretamente após uma atribuição de variável).

Então, nada desse tipo de bobagem:

try EmitEvent(try (try DecodeMsg(m)).SaveToDB())

mas sim isso:

dm := try DecodeMsg(m)
um := try dm.SaveToDB()
try EmitEvent(um)

que ainda parece mais claro do que isso:

dm, err := DecodeMsg(m)
if err != nil {
    return nil, err
}

um, err := dm.SaveToDB()
if err != nil {
    return nil, err
}

err = EmitEvent(um)
if err != nil {
    return nil, err
}

Uma coisa que eu gosto neste design é que é impossível ignorar silenciosamente os erros sem ainda anotar que um pode ocorrer . Considerando que agora, você às vezes vê x, _ := SomeFunc() (qual é o valor de retorno ignorado? um erro? algo mais?), agora você tem que anotar claramente:

x := try SomeFunc() else err {}

Desde meu post anterior em apoio à proposta, vi duas ideias postadas por @jagv (parameterless try retorna *error ) e por @josharian (rotulados manipuladores de erros) que acredito em um forma ligeiramente modificada melhoraria consideravelmente a proposta.

Juntando essas ideias com outra que eu mesmo tive, teríamos quatro versões de try :

1. experimentar()
2. tente(parâmetros)
3. try(params, label)
4. try(params, panic)

1 simplesmente retornaria um ponteiro para o parâmetro de retorno de erro (ERP) ou nil se não houvesse um (somente #4). Isso forneceria uma alternativa a um ERP nomeado sem a necessidade de adicionar mais um integrado.

2 funcionaria exatamente como atualmente previsto. Um erro não nulo seria retornado imediatamente, mas poderia ser decorado por uma instrução defer .

3 funcionaria como sugerido por @josharian , ou seja, em um erro não nulo, o código seria ramificado para o rótulo. No entanto, não haveria nenhum rótulo de manipulador de erro padrão, pois esse caso agora degeneraria em #2.

Parece-me que essa geralmente será uma maneira melhor de decorar erros (ou manipulá-los localmente e retornar nil) do que defer , pois é mais simples e rápido. Quem não gostou ainda pode usar o número 2.

Seria uma prática recomendada colocar o rótulo/código de tratamento de erros próximo ao final da função e não voltar para o restante do corpo da função. No entanto, não acho que o compilador deva aplicar, pois pode haver ocasiões estranhas em que eles são úteis e a aplicação pode ser difícil em qualquer caso.

Portanto, o rótulo normal e o comportamento goto aplicariam o assunto (como @josharian disse) ao #26058 sendo corrigido primeiro, mas acho que deve ser corrigido de qualquer maneira.

O nome do rótulo não pode ser panic , pois isso entraria em conflito com #4.

4 seria panic imediatamente em vez de retornar ou ramificar. Conseqüentemente, se esta fosse a única versão de try usada em uma função específica, nenhum ERP seria necessário.

Eu adicionei isso para que o pacote de teste possa funcionar como funciona agora, sem a necessidade de outras alterações internas ou outras. No entanto, também pode ser útil em outros cenários _fatal_.

Isso precisa ser uma versão separada de try , pois a alternativa de ramificar para um manipulador de erros e entrar em pânico com isso ainda exigiria um ERP.

Um dos tipos mais fortes de reações à proposta inicial foi a preocupação em perder a visibilidade fácil do fluxo normal de onde uma função retorna.

Por exemplo, @deanveloper expressou essa preocupação muito bem em https://github.com/golang/go/issues/32437#issuecomment -498932961, que eu acho que é o comentário mais votado aqui.

@dominikh escreveu em https://github.com/golang/go/issues/32437#issuecomment -499067357:

No código gofmt'ed, um return sempre corresponde a /^\t*return / – é um padrão muito trivial para detectar a olho nu, sem qualquer assistência. try, por outro lado, pode ocorrer em qualquer lugar no código, aninhado arbitrariamente nas chamadas de função. Nenhuma quantidade de treinamento nos tornará capazes de identificar imediatamente todo o fluxo de controle em uma função sem a ajuda da ferramenta.

Para ajudar com isso, @brynbellomy sugeriu ontem:

qualquer instrução try (mesmo aquelas sem um manipulador) deve ocorrer em sua própria linha.

Levando isso adiante, o try pode ser necessário para ser o início da linha, mesmo para uma atribuição.

Então pode ser:

try dm := DecodeMsg(m)
try um := dm.SaveToDB()
try EmitEvent(um)

em vez do seguinte (do exemplo de @brynbellomy ):

dm, err := DecodeMsg(m)
if err != nil {
    return nil, err
}

um, err := dm.SaveToDB()
if err != nil {
    return nil, err
}

err = EmitEvent(um)
if err != nil {
    return nil, err
}

Isso parece preservar uma boa quantidade de visibilidade, mesmo sem qualquer editor ou assistência de IDE, enquanto ainda reduz o clichê.

Isso pode funcionar com a abordagem baseada em adiamento proposta atualmente que depende de parâmetros de resultado nomeados ou pode funcionar com a especificação de funções de manipulador normais. (Especificar funções de manipulador sem exigir valores de retorno nomeados me parece melhor do que exigir valores de retorno nomeados, mas esse é um ponto separado).

A proposta inclui este exemplo:

info := try(try(os.Open(file)).Stat())    // proposed try built-in

Isso poderia ser em vez disso:

try f := os.Open(file)
try info := f.Stat()

Isso ainda é uma redução no clichê comparado ao que alguém pode escrever hoje, mesmo que não seja tão curto quanto a sintaxe proposta. Talvez isso seria suficientemente curto?

@elagergren-spideroak forneceu este exemplo:

try(try(try(to()).parse().this)).easily())

Eu acho que tem parênteses incompatíveis, o que talvez seja um ponto deliberado ou um pouco de humor sutil, então não tenho certeza se esse exemplo pretende ter 2 try ou 3 try . De qualquer forma, talvez seja melhor exigir que isso seja distribuído em 2-3 linhas que comecem com try .

@thepudds , era isso que eu queria chegar no meu comentário anterior. Exceto aquele dado

try f := os.Open(file)
try info := f.Stat()

Uma coisa óbvia a fazer é pensar em try como um bloco try onde mais de uma frase pode ser colocada entre parênteses. Assim, o acima pode se tornar

try (
    f := os.Open(file)
    into := f.Stat()
)

Se o compilador souber como lidar com isso, a mesma coisa funciona para o aninhamento também. Então agora o acima pode se tornar

try info := os.Open(file).Stat()

A partir de assinaturas de funções o compilador sabe que Open pode retornar um valor de erro e como está em um bloco try, ele precisa gerar tratamento de erros e então chamar Stat() no valor retornado primário e assim por diante.

A próxima coisa é permitir instruções onde não há nenhum valor de erro sendo gerado ou é tratado localmente. Então agora você pode dizer

try (
    f := os.Open(file)
    debug("f: %v\n", f) // debug returns nothing
    into := f.Stat()
)

Isso permite a evolução do código sem reorganizar os blocos try. Mas, por alguma estranha razão, as pessoas parecem pensar que o tratamento de erros deve ser explicado explicitamente! Eles querem

try(try(try(to()).parse()).this)).easily())

Enquanto eu estou perfeitamente bem com

try to().parse().this().easily()

Mesmo que em ambos os casos exatamente o mesmo código de verificação de erros possa ser gerado. Minha opinião é que você sempre pode escrever um código especial para tratamento de erros, se precisar. try (ou como você preferir chamá-lo) simplesmente organiza o tratamento de erros padrão (que é direcioná-lo para o chamador).

Outro benefício é que, se o compilador gerar o tratamento de erros padrão, ele poderá adicionar mais algumas informações de identificação para que você saiba qual das quatro funções acima falhou.

Eu estava um pouco preocupado com a legibilidade de programas onde try aparece dentro de outras expressões. Então eu corri grep "return .*err$" na biblioteca padrão e comecei a ler os blocos aleatoriamente. Existem 7214 resultados, eu li apenas algumas centenas.

A primeira coisa a ser observada é que onde try se aplica, torna quase todos esses blocos um pouco mais legíveis.

A segunda coisa é que muito poucos deles, menos de 1 em 10, colocariam try dentro de outra expressão. O caso típico são declarações da forma x := try(...) ou ^try(...)$ .

Aqui estão alguns exemplos em que try apareceria dentro de outra expressão:

texto/modelo

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        lessOrEqual, err := le(arg1, arg2)
        if err != nil {
                return false, err
        }
        return !lessOrEqual, nil
}

torna-se:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        return !try(le(arg1, arg2)), nil
}

texto/modelo

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
...
        switch v.Kind() {
        case reflect.Map:
                index, err := prepareArg(index, v.Type().Key())
                if err != nil {
                        return reflect.Value{}, err
                }
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

torna-se

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                if x := v.MapIndex(try(prepareArg(index, v.Type().Key()))); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

(este é o exemplo mais questionável que vi)

regexp/sintaxe:

regexp/syntax/parse.go

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        if c, t, err = nextRune(t); err != nil {
                return nil, err
        }
        p.literal(c)
        ...
}

torna-se

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        c, t = try(nextRune(t))
        p.literal(c)
        ...
}

Este não é um exemplo de try dentro de outra expressão, mas quero chamá-lo porque melhora a legibilidade. É muito mais fácil ver aqui que os valores de c e t estão além do escopo da instrução if.

net/http

net/http/request.go:readRequest

        mimeHeader, err := tp.ReadMIMEHeader()
        if err != nil {
                return nil, err
        }
        req.Header = Header(mimeHeader)

torna-se:

        req.Header = Header(try(tp.ReadMIMEHeader())

banco de dados/sql

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                connector, err := driverCtx.OpenConnector(dataSourceName)
                if err != nil {
                        return nil, err
                }
                return OpenDB(connector), nil
        }

torna-se

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                return OpenDB(try(driverCtx.OpenConnector(dataSourceName))), nil
        }

banco de dados/sql

        si, err := ctxDriverPrepare(ctx, dc.ci, query)
        if err != nil {
                return nil, err
        }
        ds := &driverStmt{Locker: dc, si: si}

torna-se

        ds := &driverStmt{
                Locker: dc,
                si: try(ctxDriverPrepare(ctx, dc.ci, query)),
        }

net/http

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                cc, err := p.t.dialclientconn(addr, singleuse)
                if err != nil {
                        return nil, err
                }
                return cc, nil
        }

torna-se

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                return try(p.t.dialclientconn(addr, singleuse))
        }

net/http

func (f *http2Framer) endWrite() error {
        ...
        n, err := f.w.Write(f.wbuf)
        if err == nil && n != len(f.wbuf) {
                err = io.ErrShortWrite
        }
        return err
}

torna-se

func (f *http2Framer) endWrite() error {
        ...
        if try(f.w.Write(f.wbuf) != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

(Esse eu gosto muito.)

net/http

        if f, err := fr.ReadFrame(); err != nil {
                return nil, err
        } else {
                hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
        }

torna-se

        hc = try(fr.ReadFrame()).(*http2ContinuationFrame)// guaranteed by checkFrameOrder

}

(Legal também.)

líquido :

        if ctrlFn != nil {
                c, err := newRawConn(fd)
                if err != nil {
                        return err
                }
                if err := ctrlFn(fd.ctrlNetwork(), laddr.String(), c); err != nil {
                        return err
                }
        }

torna-se

        if ctrlFn != nil {
                try(ctrlFn(fd.ctrlNetwork(), laddr.String(), try(newRawConn(fd))))
        }

talvez isso seja demais e, em vez disso, deveria ser:

        if ctrlFn != nil {
                c := try(newRawConn(fd))
                try(ctrlFn(fd.ctrlNetwork(), laddr.String(), c))
        }

No geral, gosto bastante do efeito de try no código de biblioteca padrão que li.

Um ponto final: Ver try aplicado para ler código além dos poucos exemplos da proposta foi esclarecedor. Acho que vale a pena considerar escrever uma ferramenta para converter automaticamente o código para usar try (onde não altera a semântica do programa). Seria interessante ler uma amostra dos diffs produzidos em relação a pacotes populares no github para ver se o que encontrei na biblioteca padrão se mantém. A saída de tal programa poderia fornecer uma visão extra sobre o efeito da proposta.

@crawshaw obrigado por fazer isso, foi ótimo vê-lo em ação. Mas vê-lo em ação me fez levar mais a sério os argumentos contra o tratamento de erros inline que até agora eu vinha descartando.

Como isso estava tão próximo da sugestão interessante do @thepudds de fazer try uma declaração, reescrevi todos os exemplos usando essa sintaxe e achei muito mais claro do que a expressão try ou o status quo, sem exigir muitas linhas extras:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                try index := prepareArg(index, v.Type().Key())
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        try c, t = nextRune(t)
        p.literal(c)
        ...
}

        try mimeHeader := tp.ReadMIMEHeader()
        req.Header = Header(mimeHeader)

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                try connector := driverCtx.OpenConnector(dataSourceName)
                return OpenDB(connector), nil
        }

Este seria sem dúvida melhor com uma expressão- try se houvesse vários campos que tivessem que ser try -ed, mas eu ainda prefiro o equilíbrio dessa troca

        try si := ctxDriverPrepare(ctx, dc.ci, query)
        ds := &driverStmt{Locker: dc, si: si}

Este é basicamente o pior caso para isso e parece bom:

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                try cc := p.t.dialclientconn(addr, singleuse)
                return cc, nil
        }

Eu debati comigo mesmo se if try seria ou deveria ser legal, mas não consegui encontrar uma explicação razoável por que não deveria ser e funciona muito bem aqui:

func (f *http2Framer) endWrite() error {
        ...
        if try n := f.w.Write(f.wbuf); n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

        try f := fr.ReadFrame()
        hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder

        if ctrlFn != nil {
                try c := newRawConn(fd)
                try ctrlFn(fd.ctrlNetwork(), laddr.String(), c)
        }

Analisar os exemplos de @crawshaw só me faz sentir mais seguro de que o fluxo de controle será muitas vezes enigmático o suficiente para ser ainda mais cuidadoso com o design. Relacionar até mesmo uma pequena quantidade de complexidade torna-se difícil de ler e fácil de estragar. Fico feliz em ver as opções consideradas, mas complicar o fluxo de controle em uma linguagem tão protegida parece excepcionalmente fora do personagem.

func (f *http2Framer) endWrite() error {
        ...
        if try(f.w.Write(f.wbuf) != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

Além disso, try não está "tentando" nada. É um "relé de proteção". Se a semântica básica da proposta estiver errada, não me surpreende que o código resultante também seja problemático.

func (f *http2Framer) endWrite() error {
        ...
        relay n := f.w.Write(f.wbuf)
        return checkShortWrite(n, len(f.wbuf))
}

Se você fizer try uma declaração, poderá usar um sinalizador para indicar qual valor de retorno e qual ação:

try c, @      := newRawConn(fd) // return
try c, <strong i="6">@panic</strong> := newRawConn(fd) // panic
try c, <strong i="7">@hname</strong> := newRawConn(fd) // invoke named handler
try c, <strong i="8">@_</strong>     := newRawConn(fd) // ignore, or invoke "ignored" handler if defined

Você ainda precisa de uma sintaxe de subexpressão (Russ afirmou que é um requisito), pelo menos para ações de pânico e ignorar.

Em primeiro lugar, aplaudo @crawshaw por dedicar um tempo para analisar cerca de 200 exemplos reais e dedicar um tempo para seu relato atencioso acima.

Segundo, @jimmyfrasche , em relação à sua resposta aqui sobre o exemplo http2Framer :

Eu debati comigo mesmo se if try seria ou deveria ser legal, mas não consegui encontrar uma explicação razoável por que não deveria ser e funciona muito bem aqui:

```
func (f *http2Framer) endWrite() erro {
...
se tentar n := fwWrite(f.wbuf); n != len(f.wbuf) {
return io.ErrShortWrite
}
retorno nulo
}

At least under what I was suggesting above in https://github.com/golang/go/issues/32437#issuecomment-500213884, under that proposal variation I would suggest `if try` is not allowed.

That `http2Framer` example could instead be:

func (f *http2Framer) endWrite() erro {
...
tente n := fwWrite(f.wbuf)
if n != len(f.wbuf) {
return io.ErrShortWrite
}
retorno nulo
}
`` That is one line longer, but hopefully still "light on the page". Personally, I think that (arguably) reads more cleanly, but more importantly it is easier to see the tentar`.

@deanveloper escreveu acima em https://github.com/golang/go/issues/32437#issuecomment -498932961:

Retornar de uma função parece ter sido uma coisa "sagra" a se fazer

Esse exemplo específico http2Framer acaba não sendo tão curto quanto poderia ser. No entanto, ele mantém o retorno de uma função mais "sacra" se try deve ser a primeira coisa em uma linha.

@crawshaw mencionou:

A segunda coisa é que muito poucos deles, menos de 1 em 10, colocariam try dentro de outra expressão. O caso típico são declarações da forma x := try(...) ou ^try(...)$.

Talvez não haja problema em ajudar apenas parcialmente esses 1 em 10 exemplos com uma forma mais restrita de try , especialmente se o caso típico desses exemplos terminar com a mesma contagem de linhas, mesmo que try seja obrigado a ser a primeira coisa em uma linha?

@jimmyfrasche

@crawshaw obrigado por fazer isso, foi ótimo vê-lo em ação. Mas vê-lo em ação me fez levar mais a sério os argumentos contra o tratamento de erros inline que até agora eu vinha descartando.

Como isso estava tão próximo da sugestão interessante do @thepudds de fazer try uma declaração, reescrevi todos os exemplos usando essa sintaxe e achei muito mais claro do que a expressão try ou o status quo, sem exigir muitas linhas extras:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

Seu primeiro exemplo ilustra bem porque eu prefiro fortemente a expressão- try . Na sua versão, tenho que colocar o resultado da chamada para le em uma variável, mas essa variável não tem significado semântico que o termo le já não implique. Portanto, não há nenhum nome que eu possa dar que não seja sem sentido (como x ) ou redundante (como lessOrEqual ). Com expression- try , nenhuma variável intermediária é necessária, então esse problema nem surge.

Prefiro não ter que gastar esforço mental inventando nomes para coisas que é melhor deixar no anonimato.

Fico feliz em dar meu apoio aos últimos posts em que try (a palavra-chave) foi movida para o início da linha. Ele realmente deve compartilhar o mesmo espaço visual que return .

Re: A sugestão de @jimmyfrasche de permitir try dentro de instruções compostas if , é exatamente o tipo de coisa que acho que muitos aqui estão tentando evitar, por alguns motivos:

• ele combina dois mecanismos de fluxo de controle muito diferentes em uma única linha
• a expressão try é realmente avaliada primeiro e pode fazer com que a função retorne, mas ela aparece após o if
• eles retornam com erros totalmente diferentes, um dos quais não vemos no código e outro que fazemos
• torna menos óbvio que o try não é manipulado, porque o bloco se parece muito com um bloco manipulador (mesmo que esteja lidando com um problema totalmente diferente)

Pode-se abordar esta situação de um ângulo ligeiramente diferente que favorece empurrar as pessoas para lidar com try s. Que tal permitir que a sintaxe try / else contenha condicionais subsequentes (que é um padrão comum com muitas funções de E/S que retornam err e n , qualquer um dos quais pode indicar um problema):

func (f *http2Framer) endWrite() error {
        // ...
        try n := f.w.Write(f.wbuf) else err {
                return errors.Wrap(err, "error writing:")
        } else if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

No caso de você não lidar com o erro retornado por .Write , você ainda teria uma anotação clara de que .Write pode errar (como apontado por @thepudds):

func (f *http2Framer) endWrite() error {
        // ...
        try n := f.w.Write(f.wbuf)
        if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

Eu apoio a resposta de @daved . Na minha opinião, cada exemplo que @crawshaw destacou se tornou menos claro e mais propenso a erros como resultado de try .

Fico feliz em dar meu apoio aos últimos posts em que try (a palavra-chave) foi movida para o início da linha. Ele realmente deve compartilhar o mesmo espaço visual que return .

Dadas as duas opções para este ponto e assumindo que uma foi escolhida e, portanto, estabeleceu um precedente para futuros recursos potenciais:

UMA.)

try f := os.Open(filepath) else err {
    return errors.Wrap(err, "can't open")
}

B.)

f := try os.Open(filepath) else err {
    return errors.Wrap(err, "can't open")
}

Qual dos dois oferece mais flexibilidade para uso futuro de novas palavras-chave? _(Não sei a resposta para isso, pois não domino a arte sombria de escrever compiladores.)_ Uma abordagem seria mais limitante do que outra?

@davecheney @daved @crawshaw
Eu tenderia a concordar com os Daves sobre isso: nos exemplos de @crawshaw , há muitas instruções try embutidas nas linhas que têm muitas outras coisas acontecendo. Realmente difícil identificar pontos de saída. Além disso, os parênteses try parecem atrapalhar bastante as coisas em alguns dos exemplos.

Ver um monte de código stdlib transformado assim é muito útil, então peguei os mesmos exemplos, mas os reescrevi de acordo com a proposta alternativa, que é mais restritiva:

• try como palavra-chave
• apenas um try por linha
• try deve estar no início de uma linha

Espero que isso nos ajude a comparar. Pessoalmente, acho que esses exemplos parecem muito mais concisos do que os originais, mas sem obscurecer o fluxo de controle. try permanece muito visível em qualquer lugar em que é usado.

texto/modelo

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        lessOrEqual, err := le(arg1, arg2)
        if err != nil {
                return false, err
        }
        return !lessOrEqual, nil
}

torna-se:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

texto/modelo

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
...
        switch v.Kind() {
        case reflect.Map:
                index, err := prepareArg(index, v.Type().Key())
                if err != nil {
                        return reflect.Value{}, err
                }
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

torna-se

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                try index := prepareArg(index, v.Type().Key())
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

regexp/sintaxe:

regexp/syntax/parse.go

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        if c, t, err = nextRune(t); err != nil {
                return nil, err
        }
        p.literal(c)
        ...
}

torna-se

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        try c, t = nextRune(t)
        p.literal(c)
        ...
}

net/http

net/http/request.go:readRequest

        mimeHeader, err := tp.ReadMIMEHeader()
        if err != nil {
                return nil, err
        }
        req.Header = Header(mimeHeader)

torna-se:

        try mimeHeader := tp.ReadMIMEHeader()
        req.Header = Header(mimeHeader)

banco de dados/sql

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                connector, err := driverCtx.OpenConnector(dataSourceName)
                if err != nil {
                        return nil, err
                }
                return OpenDB(connector), nil
        }

torna-se

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                try connector := driverCtx.OpenConnector(dataSourceName)
                return OpenDB(connector), nil
        }

banco de dados/sql

        si, err := ctxDriverPrepare(ctx, dc.ci, query)
        if err != nil {
                return nil, err
        }
        ds := &driverStmt{Locker: dc, si: si}

torna-se

        try si := ctxDriverPrepare(ctx, dc.ci, query)
        ds := &driverStmt{Locker: dc, si: si}

net/http

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                cc, err := p.t.dialclientconn(addr, singleuse)
                if err != nil {
                        return nil, err
                }
                return cc, nil
        }

torna-se

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                try cc := p.t.dialclientconn(addr, singleuse)
                return cc, nil
        }

net/http
Este não nos salva nenhuma linha, mas acho muito mais claro porque if err == nil é uma construção relativamente incomum.

func (f *http2Framer) endWrite() error {
        ...
        n, err := f.w.Write(f.wbuf)
        if err == nil && n != len(f.wbuf) {
                err = io.ErrShortWrite
        }
        return err
}

torna-se

func (f *http2Framer) endWrite() error {
        ...
        try n := f.w.Write(f.wbuf)
        if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

net/http

        if f, err := fr.ReadFrame(); err != nil {
                return nil, err
        } else {
                hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
        }

torna-se

        try f := fr.ReadFrame()
        hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
}

internet:

        if ctrlFn != nil {
                c, err := newRawConn(fd)
                if err != nil {
                        return err
                }
                if err := ctrlFn(fd.ctrlNetwork(), laddr.String(), c); err != nil {
                        return err
                }
        }

torna-se

        if ctrlFn != nil {
                try c := newRawConn(fd)
                try ctrlFn(fd.ctrlNetwork(), laddr.String(), c)
        }

@james-lawrence Em resposta a https://github.com/golang/go/issues/32437#issuecomment -500116099 : Não me lembro de ideias como , err opcionais sendo seriamente consideradas, não. Pessoalmente, acho que é uma má ideia, porque significa que se uma função for alterada para adicionar um parâmetro error à direita, o código existente continuará a compilar, mas agirá de maneira muito diferente.

Usar defer para lidar com os erros faz muito sentido, mas leva à necessidade de nomear o erro e um novo tipo de clichê if err != nil .

Os manipuladores externos precisam fazer isso:

func handler(err *error) {
  if *err != nil {
    *err = handle(*err)
  }
} 

que é usado como

defer handler(&err)

Os manipuladores externos precisam ser escritos apenas uma vez, mas seria necessário haver duas versões de muitas funções de tratamento de erros: a que deve ser adiada e a que deve ser usada de maneira regular.

Os manipuladores internos precisam fazer isso:

defer func() {
  if err != nil {
    err = handle(err)
  }
}()

Em ambos os casos, o erro da função externa deve ser nomeado para ser acessado.

Como mencionei anteriormente no tópico, isso pode ser abstraído em uma única função:

func catch(err *error, handle func(error) error) {
  if *err != nil && handle != nil {
    *err = handle(*err)
  }
}

Isso vai contra a preocupação de @griesemer sobre a ambiguidade das funções do manipulador nil e tem seu próprio clichê defer e func(err error) error , além de ter que nomear err na função externa.

Se try acabar como uma palavra-chave, pode fazer sentido ter uma palavra-chave catch , a ser descrita abaixo também.

Sintaticamente, seria muito parecido com handle :

catch err {
  return handleThe(err)
}

Semanticamente, seria açúcar para o código do manipulador interno acima:

defer func() {
  if err != nil {
    err = handleThe(err)
  }
}()

Como é um pouco mágico, pode pegar o erro da função externa, mesmo que não tenha sido nomeada. (O err depois catch é mais como um nome de parâmetro para o bloco catch ).

catch teria a mesma restrição que try que deve estar em uma função que tenha um retorno de erro final, pois ambos são açúcares que dependem disso.

Isso não é nem de longe tão poderoso quanto a proposta original handle , mas evitaria o requisito de nomear um erro para lidar com ele e removeria o novo clichê discutido acima para manipuladores internos, tornando fácil o suficiente para não requerem versões separadas de funções para manipuladores externos.

O tratamento de erros complicado pode exigir não usar catch da mesma forma que pode exigir não usar try .

Como ambos são açúcar, não há necessidade de usar catch com try . Os manipuladores catch são executados sempre que a função retorna um erro não nil , permitindo, por exemplo, manter algum registro rápido:

catch err {
  log.Print(err)
  return err
}

ou apenas envolvendo todos os erros retornados:

catch err {
  return fmt.Errorf("foo: %w", err)
}

@ianlancetaylor

_"Acho que é uma má ideia, porque significa que, se uma função for alterada para adicionar um parâmetro error à direita, o código existente continuará a compilar, mas agirá de maneira muito diferente."_

Essa é provavelmente a maneira correta de olhar para isso, se você puder controlar o código upstream e downstream para que, se precisar alterar uma assinatura de função para também retornar um erro, poderá fazê-lo.

Mas eu pediria para você considerar o que acontece quando alguém não controla upstream ou downstream de seus próprios pacotes? E também considerar os casos de uso em que os erros podem ser adicionados e o que acontece se os erros precisarem ser adicionados, mas você não puder forçar a alteração do código downstream?

Você pode pensar em um exemplo em que alguém mudaria a assinatura para adicionar um valor de retorno? Para mim, eles normalmente se enquadram na categoria de _"Não percebi que um erro ocorreria"_ ou _"Estou me sentindo preguiçoso e não quero me esforçar porque o erro provavelmente não acontecerá". _

Em ambos os casos, posso adicionar um retorno de erro porque fica aparente que um erro precisa ser tratado. Quando isso acontecer, se eu não puder alterar a assinatura porque não quero quebrar a compatibilidade de outros desenvolvedores usando meus pacotes, o que fazer? Meu palpite é que na grande maioria das vezes o erro irá ocorrer e que o código que chamou a função que não retorna o erro agirá de forma bem diferente, _de qualquer forma._

Na verdade, raramente faço o último, mas com muita frequência faço o primeiro. Mas notei que pacotes de terceiros frequentemente ignoram a captura de erros onde eles deveriam estar, e eu sei disso porque quando eu trago seu código nos sinalizadores GoLand em laranja brilhante todas as instâncias. Eu adoraria poder enviar solicitações de pull para adicionar tratamento de erros aos pacotes que uso muito, mas se eu fizer isso, a maioria não os aceitará porque eu estaria quebrando suas assinaturas de código.

Ao não oferecer uma maneira compatível com versões anteriores de adicionar erros a serem retornados por funções, os desenvolvedores que distribuem código e se preocupam em não quebrar as coisas para seus usuários não poderão evoluir seus pacotes para incluir o tratamento de erros como deveriam.

Talvez, em vez de considerar o problema como o código agirá de forma diferente, veja o problema como um desafio de engenharia sobre como minimizar a desvantagem de um método que não está capturando ativamente um erro? Isso teria um valor mais amplo e de longo prazo.

Por exemplo, considere adicionar um manipulador de erros de pacote que deve ser definido antes de poder ignorar erros?

Para ser franco, o idioma de Go de retornar erros, além de valores de retorno regulares, foi uma de suas melhores inovações. Mas, como muitas vezes acontece quando você melhora as coisas, muitas vezes expõe outras fraquezas e eu argumentarei que o tratamento de erros de Go não inovou o suficiente.

Nós, Gophers, nos tornamos mergulhados em retornar um erro em vez de lançar uma exceção, então a pergunta que tenho é _"Por que não deveríamos retornar erros de todas as funções?"_ Nem sempre fazemos isso porque escrever código sem tratamento de erros é mais conveniente do que codificar com ele. Portanto, omitimos o tratamento de erros quando achamos que podemos nos livrar dele. Mas frequentemente adivinhamos errado.

Então, realmente, se fosse possível descobrir como tornar o código elegante e legível, eu argumentaria que valores de retorno e erros realmente deveriam ser tratados separadamente, e que _toda_ função deveria ter a capacidade de retornar erros independentemente de suas assinaturas de função anteriores. E obter o código existente para lidar com o código que agora gera erros seria um esforço que valeria a pena.

Eu não propus nada porque não consegui imaginar uma sintaxe viável, mas se quisermos ser honestos conosco, tudo neste tópico e relacionado ao tratamento de erros do Go em geral foi sobre o fato de que o tratamento de erros e lógica do programa são companheiros estranhos, então, idealmente, os erros seriam melhor tratados fora da banda de alguma forma?

try como palavra-chave certamente ajuda na legibilidade (vs. uma chamada de função) e parece menos complexo. @brynbellomy @crawshaw obrigado por dedicar um tempo para escrever os exemplos.

Suponho que meu pensamento geral é que try faz demais. Ele resolve: chamar função, atribuir variáveis, verificar erro e retornar erro se existir. Proponho que, em vez disso, cortemos o escopo e resolvamos apenas o retorno condicional: "retorne se o último argumento não for nil".

Esta provavelmente não é uma ideia nova... Mas depois de examinar as propostas no wiki de feedback de erros , não a encontrei (não significa que não esteja lá)

Mini proposta de devolução condicional

excerto:

err, thing := newThing(name)
refuse nil, err

Eu adicionei ao wiki também em "idéias alternativas"

Não fazer nada também parece uma opção muito razoável.

@alexhornbake que me dá uma ideia um pouco diferente que seria mais útil

assert(nil, err)
assert(len(a), len(b))
assert(true, condition)
assert(expected, given)

dessa forma, não se aplicaria apenas à verificação de erros, mas a muitos tipos de erros lógicos.

O dado seria envolvido em um erro e retornado.

@alexhornbake

Assim como try não está realmente tentando, refuse não está realmente "recusando". A intenção comum aqui é que estamos definindo um "relé de proteção" ( relay é curto, preciso e aliterativo para return ) que "dispara" quando um dos valores com fio atende a uma condição (ou seja, é um erro não nulo). É uma espécie de disjuntor e, acredito, pode agregar valor se seu design for limitado a casos desinteressantes para simplesmente reduzir alguns dos clichês mais baixos. Qualquer coisa remotamente complexa deve depender do código Go simples.

Eu também recomendo Cranshaw por seu trabalho olhando através da biblioteca padrão, mas cheguei a uma conclusão muito diferente... Acho que isso torna quase todos esses trechos de código mais difíceis de ler e mais propensos a mal-entendidos.

        req.Header = Header(try(tp.ReadMIMEHeader())

Muitas vezes sentirei falta de que isso pode dar erro. Uma leitura rápida me dá "ok, defina o cabeçalho para Header of ReadMimeHeader of the thing".

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                return OpenDB(try(driverCtx.OpenConnector(dataSourceName))), nil
        }

Este, meus olhos apenas cruzam tentando analisar essa linha do OpenDB. Há tanta densidade lá... Isso mostra o maior problema que todas as chamadas de função aninhadas têm, em que você tem que ler de dentro para fora, e você tem que analisá-lo em sua cabeça para descobrir onde está a parte mais interna .

Observe também que isso pode retornar de dois lugares diferentes na mesma linha... você estará depurando, e dirá que houve um erro retornado dessa linha, e a primeira coisa que todos farão é tentar descubra por que o OpenDB está falhando com esse erro estranho, quando na verdade é o OpenConnector falhando (ou vice-versa).

        ds := &driverStmt{
                Locker: dc,
                si: try(ctxDriverPrepare(ctx, dc.ci, query)),
        }   

Este é um lugar onde o código pode falhar onde anteriormente seria impossível. Sem try , a construção literal de estrutura não pode falhar . Meus olhos passarão por ele como "ok, construindo um driverStmt ... seguindo em frente ..." e será tão fácil perder que, na verdade, isso pode causar um erro na sua função. A única maneira que teria sido possível antes é se ctxDriverPrepare entrasse em pânico... e todos nós sabemos que é um caso que 1.) basicamente nunca deveria acontecer e 2.) se acontecer, significa que algo está drasticamente errado.

Tentar uma palavra-chave e uma declaração corrige muitos dos meus problemas com ela. Eu sei que não é compatível com versões anteriores, mas não acho que usar uma versão pior seja a solução para o problema de compatibilidade com versões anteriores.

@daved Não tenho certeza se sigo. Você não gosta do nome, ou não gosta da ideia?

De qualquer forma, postei isso aqui como uma alternativa... Se houver interesse legítimo, posso abrir um novo tópico para discussão, não quero poluir este tópico (talvez tarde demais?) Polegares para cima/baixo na ideia original darão nos uma sensação... Claro aberto a nomes alternativos. A parte importante é "retorno condicional sem tentar manipular a atribuição".

Embora eu goste da proposta de captura de @jimmyfrasche , gostaria de propor uma alternativa:
go handler fmt.HandleErrorf("copy %s %s", src, dst)
seria equivalente a:
go defer func(){ if(err != nil){ fmt.HandleErrorf(&err,"copy %s %s", src, dst) } }()
onde err é o último valor de retorno nomeado, com erro de tipo. No entanto, os manipuladores também podem ser usados ​​quando os valores de retorno não são nomeados. O caso mais geral também seria permitido:
go handler func(err *error){ *err = fmt.Errorf("foo: %w", *err) }() `
O principal problema que tenho com o uso de valores de retorno nomeados (que catch não resolve) é que err é supérfluo. Ao adiar uma chamada para um manipulador como fmt.HandleErrorf , não há um primeiro argumento razoável, exceto um ponteiro para o valor de retorno do erro, por que dar ao usuário a opção de cometer um erro?

Comparado com catch, a principal diferença é que handler torna um pouco mais fácil chamar handlers predefinidos ao custo de tornar mais detalhado para defini-los no local. Não tenho certeza se isso é o ideal, mas acho que está mais de acordo com a proposta original.

@yiyus catch , como eu defini, não requer que err seja nomeado na função que contém o catch .

Em catch err { , o err é o nome do erro dentro do bloco catch . É como um nome de parâmetro de função.

Com isso, não há necessidade de algo como fmt.HandleErrorf porque você pode simplesmente usar o fmt.Errorf normal:

func f() error {
  catch err {
    return fmt.Errorf("foo: %w", err)
  }
  return errors.New("bar")
}

que retorna um erro que é impresso como foo: bar .

Eu não gosto dessa abordagem, por causa de:

• A chamada de função try() interrompe a execução do código na função pai.
• não há nenhuma palavra-chave return , mas o código realmente retorna.

Muitas maneiras de fazer manipuladores estão sendo propostas, mas acho que muitas vezes faltam dois requisitos principais:

1. Tem que ser significativamente diferente e melhor do que if x, err := thingie(); err != nil { handle(err) } . Acho que sugestões ao longo das linhas de try x := thingie else err { handle(err) } não atendem a essa barra. Por que não dizer if ?

2. Deve ser ortogonal à funcionalidade existente de defer . Ou seja, deve ser diferente o suficiente para que fique claro que o mecanismo de manipulação proposto é necessário por si só, sem criar casos de canto estranhos quando manipular e diferir interagem.

Por favor, mantenha esses desideratos em mente enquanto discutimos mecanismos alternativos para try /handle.

@carlmjohnson Eu gosto da ideia de catch de @jimmyfrasche em relação ao seu ponto 2 - é apenas açúcar de sintaxe para um defer que economiza 2 linhas e permite evitar ter que nomear o valor de retorno do erro (que em turn também exigiria que você nomeasse todos os outros, se ainda não o tivesse feito). Não levanta um problema de ortogonalidade com defer , porque é defer .

ecoando o que @ubombi disse:

A chamada da função try() interrompe a execução do código na função pai.; não há palavra-chave de retorno, mas o código realmente retorna.

Em Ruby, procs e lambdas são um exemplo do que try faz... Um proc é um bloco de código que sua instrução return retorna não do próprio bloco, mas do chamador.

Isso é exatamente o que try faz... é apenas um proc Ruby pré-definido.

Acho que se fôssemos por esse caminho, talvez pudéssemos deixar o usuário definir sua própria função try introduzindo proc functions

Ainda prefiro if err != nil , porque é mais legível, mas acho que try seria mais benéfico se o usuário definisse seu próprio proc:

proc try(err *error, msg string) {
  if *err != nil {
    *err = fmt.Errorf("%v: %w", msg, *err)
    return
  }
}

E então você pode chamá-lo:

func someFunc() (string, error) {
  err := doSomething()
  try(&err, "someFunc failed")
}

O benefício aqui é que você define o tratamento de erros em seus próprios termos. E você também pode fazer um proc exposto, privado ou interno.

Também é melhor do que a cláusula handle {} na proposta Go2 original porque você pode definir isso apenas uma vez para toda a base de código e não em cada função.

Uma consideração para legibilidade é que um func() e um proc() podem ser chamados de forma diferente, como func() e proc!() para que um programador saiba que uma chamada de proc pode realmente retornar do função de chamada.

@marwan-at-work, try(err, "someFunc failed") não deveria ser try(&err, "someFunc failed") no seu exemplo?

@dpinela obrigado pela correção, atualizei o código :)

A prática comum que estamos tentando substituir aqui é o que o desenrolamento de pilha padrão em muitos idiomas sugere em uma exceção (e, portanto, a palavra "tentar" foi selecionada ...).
Mas se pudéssemos apenas permitir uma função (...try() ou outra) que retrocedesse dois níveis no rastreamento, então

try := handler(err error) {     //which corelates with - try := func(err error) 
   if err !=nil{
       //do what ever you want to do when there's an error... log/print etc
       return2   //2 levels
   }
} 

e, em seguida, um código como
f := try(os.Open(nome do arquivo))
poderia fazer exatamente como a proposta aconselha, mas como é uma função (ou na verdade uma "função de manipulador") o desenvolvedor terá muito mais controle sobre o que a função faz, como formata o erro em diferentes casos, use um manipulador semelhante em todos os lugares o código para manipular (digamos) os.Open, em vez de escrever fmt.Errorf("erro ao abrir arquivo %s ....") todas as vezes.
Isso também forçaria o tratamento de erros como se "try" não fosse definido - é um erro de tempo de compilação.

@guybrand Ter um retorno de dois níveis return2 (ou "retorno não local", como o conceito geral é chamado em Smalltalk) seria um bom mecanismo de propósito geral (também sugerido por @mikeschinkel em #32473) . Mas parece que try ainda é necessário em sua sugestão, então não vejo uma razão para o return2 - o try pode apenas fazer o return . Seria mais interessante se também se pudesse escrever try localmente, mas isso não é possível para assinaturas arbitrárias.

@griesemer

_"então eu não vejo uma razão para o return2 - o try pode apenas fazer o return ."_

Uma razão - como apontei em #32473 _(obrigado pela referência)_ - seria permitir vários níveis de break e continue , além de return .

Obrigado novamente a todos por todos os novos comentários; é um investimento de tempo significativo para acompanhar a discussão e escrever um feedback extenso. E melhor ainda, apesar dos argumentos às vezes apaixonados, este tem sido um tópico bastante civilizado até agora. Obrigado!

Aqui está outro resumo rápido, desta vez um pouco mais condensado; desculpas para aqueles que eu não mencionei, esqueci ou representei errado. Neste ponto, acho que alguns temas maiores estão surgindo:

1) Em geral, usar um built-in para a funcionalidade try é considerado uma má escolha: Dado que afeta o fluxo de controle, deve ser _pelo menos_ uma palavra-chave ( @carloslenz "prefere fazer uma declaração sem parêntese"); try como expressão não parece uma boa ideia, prejudica a legibilidade ( @ChrisHines , @jimmyfrasche), são "retornos sem return ". @brynbellomy fez uma análise real de try usados ​​como identificadores; parece haver muito poucos em termos de porcentagem, então pode ser possível seguir a rota da palavra-chave sem afetar muito código.

2) @crawshaw levou algum tempo para analisar algumas centenas de casos de uso da biblioteca std e chegou à conclusão de que try , conforme proposto, quase sempre melhorava a legibilidade. @jimmyfrasche chegou à conclusão oposta .

3) Outro tema é que usar defer para decoração de erros não é o ideal. @josharian aponta que os defer 's sempre são executados no retorno da função, mas se eles estão aqui para decoração de erro, nós só nos importamos com seu corpo se houver um erro, o que pode ser uma fonte de confusão.

4) Muitos escreveram sugestões para melhorar a proposta. @zeebo , @patrick-nyt apoiam gofmt formatando simples if em uma única linha (e fique feliz com o status quo). @jargv sugeriu que try() (sem argumentos) poderia retornar um ponteiro para o erro "pendente" atualmente, o que removeria a necessidade de nomear o resultado do erro apenas para que se tenha acesso a ele em um defer ; @masterada sugeriu usar errorfunc() . @velovix reviveu a ideia de um try de 2 argumentos onde o segundo argumento seria um manipulador de erros.

@klaidliadon , @networkimprov são a favor de "operadores de atribuição" especiais, como f, # := os.Open() em vez de try . A @networkimprov apresentou uma proposta alternativa mais abrangente investigando essas abordagens (consulte a edição nº 32500). @mikeschinkel também apresentou uma proposta alternativa sugerindo a introdução de dois novos recursos de linguagem de uso geral que também poderiam ser usados ​​para tratamento de erros, em vez de um try específico de erro (consulte a edição #32473). @josharian reviveu uma possibilidade que discutimos na GopherCon no ano passado, onde try não retorna após um erro, mas pula (com goto ) para um rótulo chamado error (alternativamente , try pode ter o nome de um rótulo de destino).

5) Sobre o tema try como palavra-chave, surgiram duas linhas de pensamento. @brynbellomy sugeriu uma versão que pode, alternativamente, especificar um manipulador:

a, b := try f()
a, b := try f() else err { /* handle error */ }

@thepudds vai um passo além e sugere try no início da linha, dando try a mesma visibilidade que um return :

try a, b := f()

Ambos podem funcionar com defer .

@griesemer

Obrigado pela referência a @mikeschinkel #32473, tem muito em comum.

em relação a

Mas parece que ainda é necessário tentar na sua sugestão
Embora minha sugestão possa ser implementada com "qualquer" manipulador e não com um "build in/keyword/expression" reservado, não acho que "try()" seja uma má ideia (e, portanto, não votei negativamente), estou tentando para "ampliá-lo" - para mostrar mais vantagens, muitos esperavam "uma vez que o go 2.0 fosse introduzido"

Eu acho que isso também pode ser a fonte das "vibrações mistas" que você relatou em seu último resumo - não é "try() não melhora o tratamento de erros" - com certeza sim, está "esperando que o Go 3.0 resolva algum outro erro importante" lidar com dores" as pessoas afirmaram acima, parece muito longo :)

Estou conduzindo uma pesquisa sobre "dores de manipulação de erros" (e alguns dos problemas são apenas "eu não uso boas práticas", enquanto alguns eu nem imaginava que as pessoas (principalmente vindas de outros idiomas) quisessem fazer - de legal para WTF).

Espero poder compartilhar alguns resultados interessantes em breve.

por último -Obrigado pelo incrível trabalho e paciência!

Olhando simplesmente para o comprimento da sintaxe proposta atual versus o que está disponível agora, o caso em que o erro só precisa ser retornado sem manipulá-lo ou decorado é o caso em que a maior conveniência é obtida. Um exemplo com minha sintaxe favorita até agora:

try a, b := f() else err { return fmt.Errorf("Decorated: %s", err); }
if a,b, err :=f;  err != nil { return fmt.Errorf("Decorated: %s", err); }
try a, b := f()
if a,b, err :=f;  err != nil { return err; }

Então, diferente do que eu pensava antes, talvez seja simplesmente suficiente alterar go fmt, pelo menos para o caso de erro decorado/tratado. Enquanto para apenas passar o caso de erro, algo como try ainda pode ser desejável como açúcar sintático para este caso de uso muito comum.

Em relação try else , acho que funções de erro condicional como fmt.HandleErrorf (editar: estou assumindo que retorna nil quando a entrada é nil) no comentário inicial funciona bem, então adicionar else é desnecessário.

a, b, err := doSomething()
try fmt.HandleErrorf(&err, "Decorated "...)

Como muitos outros aqui, prefiro que try seja uma declaração em vez de uma expressão, principalmente porque uma expressão que altera o fluxo de controle é completamente estranha ao Go. Também porque isso não é uma expressão, deve estar no início da linha.

Também concordo com @daved que o nome não é apropriado. Afinal, o que estamos tentando alcançar aqui é uma atribuição protegida, então por que não usar guard como em Swift e tornar a cláusula else opcional? Algo como

GuardStmt = "guard" ( Assignment | ShortVarDecl | Expression ) [  "else" Identifier Block ] .

em que Identifier é o nome da variável de erro vinculada no seguinte Block . Sem a cláusula else , apenas retorne da função atual (e use um manipulador de defer para decorar erros, se necessário).

Inicialmente, não gostei de uma cláusula else porque é apenas um açúcar sintático em torno da atribuição usual seguida por if err != nil , mas depois de ver alguns dos exemplos, faz sentido: usar guard torna a intenção mais clara.

EDIT: alguns sugeriram usar coisas como catch para especificar de alguma forma diferentes manipuladores de erros. Acho else igualmente viável semanticamente falando e já está no idioma.

Embora eu goste da instrução try-else, que tal essa sintaxe?

a, b, (err) := func() else { return err }

A expressão try - else é um operador ternário.

a, b := try f() else err { ... }
fmt.Println(try g() else err { ... })`

Declaração try - else é uma declaração if .

try a, b := f() else err { ... }
// (modulo scope of err) same as
a, b, err := f()
if err != nil { ... }

try com um manipulador opcional pode ser obtido com uma função auxiliar (abaixo) ou não usando try (não ilustrado, todos nós sabemos como é).

a, b := try(f(), decorate)
// same as
a, b := try(g())
// where g is
func g() (whatever, error) {
  x, err := f()
  if err != nil {
    try(decorate(err))
  }
  return x, nil
}

Todos os três reduzem o clichê e ajudam a conter o escopo dos erros.

Ele oferece a maior economia para try embutido, mas isso tem os problemas mencionados no documento de design.

Para o extrato try - else , ele oferece uma vantagem sobre o uso if em vez de try . Mas a vantagem é tão marginal que tenho dificuldade em vê-la se justificar, embora goste dela.

Todos os três assumem que é comum precisar de tratamento de erros especial para erros individuais.

O tratamento de todos os erros igualmente pode ser feito em defer . Se o mesmo tratamento de erros está sendo feito em cada bloco else , isso é um pouco repetitivo:

func printSum(a, b string) error {
  try x := strconv.Atoi(a) else err {
    return fmt.Errorf("printSum: %w", err)
  }
  try y := strconv.Atoi(b) else err {
    return fmt.Errorf("printSum: %w", err)
  }
  fmt.Println("result:", x + y)
  return nil
}

Eu certamente sei que há momentos em que um determinado erro requer tratamento especial. Essas são as instâncias que ficam na minha memória. Mas, se isso acontecer, digamos, 1 em cada 100 vezes, não seria melhor manter try simples e não usar try nessas situações? Por outro lado, se for mais como 1 em cada 10 vezes, adicionar else /handler parece mais razoável.

Seria interessante ver uma distribuição real de quantas vezes try sem um else /handler vs try com um else /handler seria útil, embora não são dados fáceis de coletar.

Quero expandir o comentário recente de @jimmyfrasche .

O objetivo desta proposta é reduzir o clichê

    a, b, err := f()
    if err != nil {
        return nil, err
    }

Este código é fácil de ler. Só vale a pena estender a linguagem se conseguirmos uma redução considerável no clichê. Quando eu vejo algo como

    try a, b := f() else err { return nil, err }

Não posso deixar de sentir que não estamos economizando tanto. Estamos salvando três linhas, o que é bom, mas pelas minhas contas estamos cortando de 56 para 46 caracteres. Isso não é muito. Comparado a

    a, b := try(f())

que corta de 56 para 18 caracteres, uma redução muito mais significativa. E enquanto a declaração try torna a mudança potencial de fluxo de controle mais clara, no geral não acho a declaração mais legível. Embora no lado positivo a instrução try facilite a anotação do erro.

De qualquer forma, meu ponto é: se vamos mudar alguma coisa, isso deve reduzir significativamente o clichê ou deve ser significativamente mais legível. O último é bem difícil, então qualquer mudança precisa realmente funcionar no primeiro. Se conseguirmos apenas uma pequena redução no clichê, então, na minha opinião, não vale a pena fazer.

Como outros, gostaria de agradecer a @crawshaw pelos exemplos.

Ao ler esses exemplos, encorajo as pessoas a tentarem adotar uma mentalidade na qual você não se preocupe com o fluxo de controle devido à função try . Acredito, talvez incorretamente, que esse fluxo de controle se tornará rapidamente uma segunda natureza para as pessoas que conhecem o idioma. No caso normal, acredito que as pessoas simplesmente deixarão de se preocupar com o que acontece no caso de erro. Tente ler esses exemplos enquanto vitrifica try assim como você já vitrifica if err != nil { return err } .

Depois de ler tudo aqui, e após uma reflexão mais aprofundada, não tenho certeza se vejo tentar, mesmo como uma declaração, algo que valha a pena acrescentar.

1. a razão para isso parece estar reduzindo o código de placa de caldeira de manipulação de erros. IMHO ele "organiza" o código, mas realmente não remove a complexidade; apenas o obscurece . Isso não parece uma razão forte o suficiente. O "ir" lindamente capturada iniciando um thread simultâneo. Não tenho esse tipo de sensação de "aha!" aqui. Não parece certo. A relação custo / benefício não é grande o suficiente.

2. seu nome não reflete sua função. Em sua forma mais simples, o que ele faz é isso: "se uma função retornar um erro, retorne do chamador com um erro", mas isso é muito longo :-) No mínimo, um nome diferente é necessário.

3. com o retorno implícito do try no erro, parece que o Go está meio que relutantemente voltando para o tratamento de exceções. Isto é, se A chama em um try guard e B chama C em um try guard, e C chama D em um try guard, se D retornar um erro com efeito, você causou um goto não local. Parece muito "mágico".

4. e ainda acredito que uma maneira melhor pode ser possível. Escolher tentar agora fechará essa opção.

@ianlancetaylor
Se eu entendi a proposta "try else" corretamente, parece que o bloco else é opcional e reservado para o manuseio fornecido pelo usuário. No seu exemplo try a, b := f() else err { return nil, err } a cláusula else é realmente redundante, e a expressão inteira pode ser escrita simplesmente como try a, b := f()

Concordo com @ianlancetaylor ,
Legibilidade e clichê são duas preocupações principais e talvez o impulso para
o tratamento de erros do go 2.0 (embora eu possa adicionar algumas outras preocupações importantes)

Também, que a corrente

a, b, err := f()
if err != nil {
    return nil, err
}

É altamente legível.
E já que eu acredito

if a, b, err := f(); err != nil {
    return nil, err
}

É quase tão legível, mas teve seus "problemas" de escopo, talvez um

ifErr a, b, err := f() {
    return nil, err
}

Isso seria apenas o ; err != nil part, e não criaria um escopo, ou

similarmente

tente a, b, err := f() {
retornar zero, err
}

Mantém as duas linhas extras, mas ainda é legível.

Em terça-feira, 11 de junho de 2019, 20:19 Dmitriy Matrenichev, [email protected]
escrevi:

@ianlancetaylor https://github.com/ianlancetaylor
Se eu entendi a proposta "tente mais" corretamente, parece que o bloco else
é opcional e reservado para manuseio fornecido pelo usuário. No seu exemplo
tente a, b := f() else err { return nil, err } a cláusula else é na verdade
redundante, e toda a expressão pode ser escrita simplesmente como try a, b :=
f()

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=ABNEY4XPURMASWKZKOBPBVDPZ7NALA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXN3VDA#issuecomment-500933LNMVXHJKTDN5WW2ZLOORPWSZGODXN3VDA#issuecomment-50093
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/ABNEY4SAFK4M5NLABF3NZO3PZ7NALANCNFSM4HTGCZ7Q
.

@ianlancetaylor

De qualquer forma, meu ponto é: se vamos mudar alguma coisa, isso deve reduzir significativamente o clichê ou deve ser significativamente mais legível. O último é bem difícil, então qualquer mudança precisa realmente funcionar no primeiro. Se conseguirmos apenas uma pequena redução no clichê, então, na minha opinião, não vale a pena fazer.

Concordo, e considerando que um else seria apenas açúcar sintático (com uma sintaxe estranha!), muito provavelmente usado apenas raramente, não me importo muito com isso. Eu ainda prefiro try para ser uma declaração.

@ianlancetaylor Ecoando @DmitriyMV , o bloco else seria opcional. Deixe-me dar um exemplo que ilustra ambos (e não parece muito errado em termos da proporção relativa de blocos try manipulados versus não manipulados em código real):

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    headRef, err := r.Head()
    if err != nil {
        return err
    }

    parentObjOne, err := headRef.Peel(git.ObjectCommit)
    if err != nil {
        return err
    }

    parentObjTwo, err := remoteBranch.Reference.Peel(git.ObjectCommit)
    if err != nil {
        return err
    }

    parentCommitOne, err := parentObjOne.AsCommit()
    if err != nil {
        return err
    }

    parentCommitTwo, err := parentObjTwo.AsCommit()
    if err != nil {
        return err
    }

    treeOid, err := index.WriteTree()
    if err != nil {
        return err
    }

    tree, err := r.LookupTree(treeOid)
    if err != nil {
        return err
    }

    remoteBranchName, err := remoteBranch.Name()
    if err != nil {
        return err
    }

    userName, userEmail, err := r.UserIdentityFromConfig()
    if err != nil {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    _, err = r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    if err != nil {
        return err
    }
    return nil
}

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    try headRef := r.Head()
    try parentObjOne := headRef.Peel(git.ObjectCommit)
    try parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    try parentCommitOne := parentObjOne.AsCommit()
    try parentCommitTwo := parentObjTwo.AsCommit()
    try treeOid := index.WriteTree()
    try tree := r.LookupTree(treeOid)
    try remoteBranchName := remoteBranch.Name()
    try userName, userEmail := r.UserIdentityFromConfig() else err {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    try r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    return nil
}

Embora o padrão try / else não economize muitos caracteres sobre o composto if , ele salva:

• unifique a sintaxe de tratamento de erros com o try não tratado
• deixar claro de relance que um bloco condicional está lidando com uma condição de erro
• nos dar uma chance de reduzir a estranheza de escopo que os compostos if sofrem de

No entanto, try não manipulados provavelmente serão os mais comuns.

@ianlancetaylor

Tente ler esses exemplos enquanto vitrifica tente assim como você já vitrifica if err != nil { return err }.

Eu não acho que isso seja possível/igualável. Perder que uma tentativa existe em uma linha lotada, ou o que ela envolve exatamente, ou que existem várias instâncias em uma linha... Isso não é o mesmo que marcar facilmente/rapidamente um ponto de retorno e não se preocupar com as especificidades nele.

@ianlancetaylor

Quando vejo um sinal de pare, reconheço-o pela forma e pela cor mais do que lendo a palavra impressa nele e ponderando suas implicações mais profundas.

Meus olhos podem vidrar sobre if err != nil { return err } mas ao mesmo tempo ainda registra - clara e instantaneamente.

O que eu gosto na variante try -statement é que ela reduz o clichê, mas de uma maneira que é fácil de esmaltar, mas difícil de perder.

Pode significar uma linha extra aqui ou ali, mas ainda é menos linhas do que o status quo.

@brynbellomy

1. Como você oferece para lidar com funções que retornam vários valores, como:
   func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) (hash , error) {
2. Como você manteria o rastreamento da linha correta que retornou o erro
3. descartando o problema de escopo (que pode ser resolvido de outras maneiras), não tenho certeza

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {

    if headRef, err := r.Head(); err != nil {
        return err
    } else if parentObjOne, err := headRef.Peel(git.ObjectCommit); err != nil {
        return err
    } else parentObjTwo, err := remoteBranch.Reference.Peel(git.ObjectCommit); err != nil {
        return err
    } ...

não é tão diferente em termos de legibilidade, ainda (ou fmt.Errorf("error with Getting head : %s", err.Error() ) permite que você modifique e forneça dados extras facilmente.

O que ainda é chato é o

1. ter que verificar novamente; err!= nada
2. retornando o erro como está se não quisermos fornecer as informações extras - o que em alguns casos não é uma boa prática, porque você depende da função que você chama para refletir um erro "bom" que indicará "o que deu errado ", em casos de file.Open , close , Remove , funções de banco de dados etc muitas das chamadas de função podem retornar o mesmo erro (podemos discutir se isso significa que o desenvolvedor que escreveu o erro fez um bom trabalho ou não ... acontece) - e então - você tem um erro, provavelmente registre-o da função que chamou
   " createMergeCommit", mas não consigo rastreá-lo até a linha exata em que ocorreu.

Desculpe se alguém já postou algo assim (há muitas boas ideias :P ) Que tal essa sintaxe alternativa:

fail := func(err error) error {
  log.Print("unexpected error", err)
  return err
}

a, b, err := f1()          // normal
c, d := f2() -> throw      // calls throw(err)
e, f := f3() -> panic      // calls panic(err)
g, h := f4() -> t.Error    // calls t.Error(err)
i, j := f5() -> fail       // calls fail(err)

ou seja, você tem um -> handler à direita de uma chamada de função que é chamada se o retorno err != nil. O manipulador é qualquer função que aceita um erro como um único argumento e, opcionalmente, retorna um erro (ou seja, func(error) ou func(error) error ). Se o manipulador retornar um erro nil, a função continuará, caso contrário, o erro será retornado.

então a := b() -> handler é equivalente a:

a, err := b()
if err != nil {
  if herr := handler(err); herr != nil {
    return herr
  }
}

Agora, como um atalho, você pode suportar um try embutido (ou palavra-chave ou operador ?= ou qualquer outra coisa) que é a abreviação de a := b() -> throw para que você possa escrever algo como:

func() error {
  a, b := try(f1())
  c, d := try(f2())
  e, f := try(f3())
  ...
  return nil
}() -> panic // or throw/fail/whatever

Pessoalmente, acho um operador ?= mais fácil de ler do que uma palavra-chave try/built-in:

func() error {
  a, b ?= f1()
  c, d ?= f2()
  e, f ?= f3()
  ...
  return nil
}() -> panic

note : aqui estou usando throw como um espaço reservado para um builtin que retornaria o erro para o chamador.

Eu não comentei sobre as propostas de tratamento de erros até agora porque geralmente sou a favor e gosto do jeito que elas estão indo. Tanto a função try definida na proposta quanto a declaração try proposta por @thepudds parecem ser adições razoáveis ​​à linguagem. Estou confiante de que o que quer que a equipe Go faça será bom.

Quero trazer à tona o que vejo como um problema menor com a maneira como o try é definido na proposta e como isso pode afetar futuras extensões.

Try é definido como uma função que recebe um número variável de argumentos.

func try(t1 T1, t2 T2, … tn Tn, te error) (T1, T2, … Tn)

Passar o resultado de uma chamada de função para try como em try(f()) funciona implicitamente devido à maneira como vários valores de retorno funcionam em Go.

Pela minha leitura da proposta, os trechos a seguir são válidos e semanticamente equivalentes.

a, b = try(f())
//
u, v, err := f()
a, b = try(u, v, err)

A proposta também levanta a possibilidade de estender try com argumentos extras.

Se determinarmos que ter alguma forma de função manipuladora de erros explicitamente fornecida, ou qualquer outro parâmetro adicional para esse assunto, é uma boa ideia, é trivialmente possível passar esse argumento adicional para uma chamada try.

Suponha que queremos adicionar um argumento de manipulador. Ele pode ir no início ou no final da lista de argumentos.

var h handler
a, b = try(h, f())
// or
a, b = try(f(), h)

Colocá-lo no início não funciona, porque (dada a semântica acima) try não seria capaz de distinguir entre um argumento de manipulador explícito e uma função que retorna um manipulador.

func f() (handler, error) { ... }
func g() (error) { ... }
try(f())
try(h, g())

Colocá-lo no final provavelmente funcionaria, mas try seria único na linguagem como sendo a única função com um parâmetro varargs no início da lista de argumentos.

Nenhum desses problemas é um impedimento, mas eles fazem try parecer inconsistente com o resto da linguagem, então não tenho certeza se try seria fácil de estender no futuro como o estados da proposta.

@mágico

Ter um manipulador é poderoso, talvez:
Eu você já declarou h,

você pode

var h handler
a, b, h = f()

ou

a, b, h.err = f()

se for um tipo de função:

h:= handler(err error){
 log(...)
 return ....
} 

Em seguida, houve a sugestão de

a, b, h(err) = f()

Todos podem invocar o manipulador
E você também pode "selecionar" o manipulador que retorna ou apenas captura o erro (conitnue/break/return) como alguns sugeriram.

E assim a questão varargs se foi.

Uma alternativa para a sugestão de else de @brynbellomy de:

a, b := try f() else err { /* handle error */ }

poderia ser para suportar uma função de decoração imediatamente após o else:

decorate := func(err error) error { return fmt.Errorf("foo failed: %v", err) }

try a, b := f() else decorate
try c, d := g() else decorate

E talvez também algumas funções utilitárias algo como:

decorate := fmt.DecorateErrorf("foo failed")

A função de decoração pode ter assinatura func(error) error , e ser chamada por try na presença de um erro, logo antes de try retornar da função associada que está sendo tentada.

Isso seria semelhante em espírito a uma das “iterações de design” anteriores do documento da proposta:

f := try(os.Open(filename), handler)              // handler will be called in error case

Se alguém quiser algo mais complexo ou um bloco de instruções, pode usar if (assim como hoje).

Dito isso, há algo de bom no alinhamento visual de try mostrado no exemplo de @brynbellomy em https://github.com/golang/go/issues/32437#issuecomment -500949780.

Tudo isso ainda pode funcionar com defer se essa abordagem for escolhida para decoração de erro uniforme (ou mesmo em teoria poderia haver uma forma alternativa de registrar uma função de decoração, mas isso é um ponto separado).

De qualquer forma, não tenho certeza do que é melhor aqui, mas queria deixar outra opção explícita.

Aqui está o exemplo de @brynbellomy reescrito com a função try , usando um bloco var para manter o bom alinhamento que @thepudds apontou em https://github.com/golang/go/issues /32437#issuecomment -500998690.

package main

import (
    "fmt"
    "time"
)

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    var (
        headRef          = try(r.Head())
        parentObjOne     = try(headRef.Peel(git.ObjectCommit))
        parentObjTwo     = try(remoteBranch.Reference.Peel(git.ObjectCommit))
        parentCommitOne  = try(parentObjOne.AsCommit())
        parentCommitTwo  = try(parentObjTwo.AsCommit())
        treeOid          = try(index.WriteTree())
        tree             = try(r.LookupTree(treeOid))
        remoteBranchName = try(remoteBranch.Name())
    )

    userName, userEmail, err := r.UserIdentityFromConfig()
    if err != nil {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    _, err = r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    return err
}

É tão sucinto quanto a versão try -statement, e eu diria que é igualmente legível. Como try é uma expressão, algumas dessas variáveis ​​intermediárias podem ser eliminadas, ao custo de alguma legibilidade, mas isso parece mais uma questão de estilo do que qualquer outra coisa.

Isso levanta a questão de como try funciona em um bloco var . Suponho que cada linha do var conta como uma instrução separada, em vez de todo o bloco ser uma única instrução, até a ordem do que é atribuído quando.

Seria bom se a proposta "tentar" chamasse explicitamente as consequências para ferramentas como cmd/cover que aproximam estatísticas de cobertura de teste usando contagem de instruções ingênuas. Eu me preocupo que o fluxo de controle de erro invisível possa resultar em subcontagem.

@thepudds

tente a, b := f() senão decore

Talvez seja uma queimadura muito profunda nas células do meu cérebro, mas isso me atinge muito como um

try a, b := f() ;catch(decorate)

e um declive escorregadio para um

a, b := f()
catch(decorate)

Eu acho que você pode ver onde isso está levando, e para mim comparando

    try headRef := r.Head()
    try parentObjOne := headRef.Peel(git.ObjectCommit)
    try parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    try parentCommitOne := parentObjOne.AsCommit()
    try parentCommitTwo := parentObjTwo.AsCommit()
    try treeOid := index.WriteTree()
    try tree := r.LookupTree(treeOid)
    try remoteBranchName := remoteBranch.Name()

com

    try ( 
    headRef := r.Head()
    parentObjOne := headRef.Peel(git.ObjectCommit)
    parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    parentCommitOne := parentObjOne.AsCommit()
    parentCommitTwo := parentObjTwo.AsCommit()
    treeOid := index.WriteTree()
    tree := r.LookupTree(treeOid)
    remoteBranchName := remoteBranch.Name()
    )

(ou até uma pegadinha no final)
O segundo é mais legível, mas enfatiza o fato de que as funções abaixo retornam 2 vars, e magicamente descartamos um, coletando-o em um "err retornado por magia" .

    try(err) ( 
    headRef := r.Head()
    parentObjOne := headRef.Peel(git.ObjectCommit)
    parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    parentCommitOne := parentObjOne.AsCommit()
    parentCommitTwo := parentObjTwo.AsCommit()
    treeOid := index.WriteTree()
    tree := r.LookupTree(treeOid)
    remoteBranchName := remoteBranch.Name()
    ); err!=nil {
      //handle the err
    }

pelo menos define explicitamente a variável para retornar, e deixe-me lidar com isso dentro da função, sempre que eu quiser.

Apenas inserindo um comentário específico, pois não vi ninguém mencionar explicitamente, especificamente sobre a alteração de gofmt para suportar a seguinte formatação de linha única ou qualquer variante:

if f() { return nil, err }

Por favor não. Se quisermos uma única linha if , faça uma única linha if , por exemplo:

if f() then return nil, err

Mas, por favor, por favor, não adote a salada de sintaxe removendo as quebras de linha que facilitam a leitura do código que usa chaves.

Gosto de enfatizar algumas coisas que podem ter sido esquecidas no calor da discussão:

1) O objetivo desta proposta é fazer com que o tratamento de erros comuns fique em segundo plano - o tratamento de erros não deve dominar o código. Mas ainda deve ser explícito. Qualquer uma das sugestões alternativas que fazem com que o tratamento de erros se destaque ainda mais está perdendo o ponto. Como @ianlancetaylor já disse, se essas sugestões alternativas não reduzirem significativamente a quantidade de clichê, podemos ficar com as declarações if . (E o pedido para reduzir o clichê vem de você, a comunidade Go.)

2) Uma das reclamações sobre a proposta atual é a necessidade de nomear o resultado do erro para ter acesso a ele. Qualquer proposta alternativa terá o mesmo problema, a menos que a alternativa introduza sintaxe extra, ou seja, mais clichê (como ... else err { ... } e similares) para nomear explicitamente essa variável. Mas o que é interessante: Se não nos importamos em decorar um erro e não nomearmos os parâmetros de resultado, mas ainda exigirmos um return explícito porque há um manipulador explícito de tipos, essa instrução return terá que enumerar todos os valores de resultado (normalmente zero), já que um retorno nu não é permitido neste caso. Especialmente se uma função faz muitos retornos de erro sem decorar o erro, esses retornos explícitos ( return nil, err , etc.) são adicionados ao clichê. A proposta atual e qualquer alternativa que não exija um return explícito acaba com isso. Por outro lado, se se quer decorar o erro, a proposta atual _requer_ que se dê um nome ao resultado do erro (e com isso todos os outros resultados) para ter acesso ao valor do erro. Isso tem o bom efeito colateral de que em um manipulador explícito pode-se usar um retorno nu e não é necessário repetir todos os outros valores de resultado. (Eu sei que existem alguns fortes sentimentos sobre retornos nu, mas a realidade é que quando tudo o que nos importa é o resultado do erro, é um verdadeiro incômodo ter que enumerar todos os outros valores de resultado (normalmente zero) - isso não acrescenta nada ao compreensão do código). Em outras palavras, ter que nomear o resultado do erro para que ele possa ser decorado permite uma redução ainda maior do clichê.

@magical Obrigado por apontar isso . Percebi o mesmo logo após postar a proposta (mas não a trouxe para não causar mais confusão). Você está certo de que, como está, try não pode ser estendido. Felizmente, a correção é bastante fácil. (Acontece que nossas propostas internas anteriores não tiveram esse problema - ele foi introduzido quando reescrevi nossa versão final para publicação e tentei simplificar try para corresponder mais às regras de passagem de parâmetros existentes. Parecia uma boa - mas como se vê, falho e principalmente inútil - benefício para poder escrever try(a, b, c, handle) .)

Uma versão anterior de try a definia aproximadamente da seguinte forma: try(expr, handler) recebe uma (ou talvez duas) expressões como argumentos, onde a primeira expressão pode ter vários valores (só pode acontecer se a expressão for uma chamada de função). O último valor dessa expressão (possivelmente com vários valores) deve ser do tipo error e esse valor é testado em relação a nil. (etc. - o resto você pode imaginar).

De qualquer forma, o ponto é que try aceita sintaticamente apenas uma, ou talvez duas expressões. (Mas é um pouco mais difícil descrever a semântica de try .) A consequência seria esse código como:

a, b := try(u, v, err)

não seria mais permitido. Mas há pouca razão para fazer isso funcionar em primeiro lugar: Na maioria dos casos (a menos que a e b sejam resultados nomeados) este código - se importante por algum motivo - pode ser reescrito facilmente em

a, b := u, v  // we don't care if the assignment happens in case of an error
try(err)

(ou use uma instrução if conforme necessário). Mas, novamente, isso parece sem importância.

essa instrução de retorno terá que enumerar todos os valores de resultado (normalmente zero), pois um retorno nu não é permitido neste caso

Um retorno nu não é permitido, mas tentar seria. Uma coisa que eu gosto em tentar (seja como uma função ou uma instrução) é que não precisarei mais pensar em como definir valores sem erro ao retornar um erro, apenas usarei try.

@griesemer Obrigado pela explicação. Essa é a conclusão a que cheguei também.

Um breve comentário sobre try como uma declaração: como acho que pode ser visto no exemplo em https://github.com/golang/go/issues/32437#issuecomment -501035322, o try enterra o lede. O código se torna uma série de instruções try , que obscurece o que o código está realmente fazendo.

O código existente pode reutilizar uma variável de erro recém-declarada após o bloco if err != nil . Ocultar a variável quebraria isso, e adicionar uma variável de retorno nomeada à assinatura da função nem sempre a corrigirá.

Talvez seja melhor deixar a declaração/atribuição de erro como está e encontrar um stmt de tratamento de erros de uma linha.

err := f() // followed by one of

on err, return err            // any type can be tested for non-zero
on err, return fmt.Errorf(...)
on err, fmt.Println(err)      // doesn't stop the function
on err, hname err             // handler invocation without parens
on err, ignore err            // optional ignore handler logs error if defined

if err, return err            // alternatively, use if

handle hname(err error, clr caller) { // type caller has results of runtime.Caller()
   if err == io.Bad { return err }
   fmt.Println(clr.name, err)
}

Uma subexpressão try pode entrar em pânico, significando que o erro nunca é esperado. Uma variante disso poderia ignorar qualquer erro.

f(try g()) // panic on error
f(try_ g()) // ignore any error

O objetivo desta proposta é fazer com que o tratamento de erros comuns fique em segundo plano - o tratamento de erros não deve dominar o código. Mas ainda deve ser explícito.

Eu gosto da ideia dos comentários listando try como uma declaração. É explícito, ainda fácil de encobrir (já que é de comprimento fixo), mas não tão fácil de encobrir (já que está sempre no mesmo lugar) que eles podem ser escondidos em uma linha lotada. Ele também pode ser combinado com o defer fmt.HandleErrorf(...) como observado anteriormente, no entanto, ele tem a armadilha de abusar de parâmetros nomeados para encapsular erros (o que ainda parece um hack inteligente para mim. hacks inteligentes são ruins.)

Uma das razões pelas quais eu não gostei de try como uma expressão é que é muito fácil de encobrir, ou não é fácil o suficiente para encobrir. Veja os dois exemplos a seguir:

Tente como uma expressão

// Too hidden, it's in a crowded function with many symbols that complicate the function.

f, err := os.OpenFile(try(FileName()), os.O_APPEND|os.O_WRONLY, 0600)

// Not easy enough, the word "try" already increases horizontal complexity, and it
// being an expression only encourages more horizontal complexity.
// If this code weren't collapsed to multiple lines, it would be extremely
// hard to read and unclear as to what's executing when.

fullContents := try(io.CopyN(
    os.Stdout,
    try(net.Dial("tcp", "localhost:"+try(buf.ReadString("\n"))),
    try(strconv.Atoi(try(buf.ReadString("\n")))),
))

Tente como uma declaração

// easy to see while still not being too verbose

try name := FileName()
os.OpenFile(name, os.O_APPEND|os.O_WRONLY, 0600)

// does not allow for clever one-liners, code remains much more readable.
// also, the code reads in sequence from top-to-bottom.

try port := r.ReadString("\n")
try lengthStr := r.ReadString("\n")
try length := strconv.Atoi(lengthStr)

try con := net.Dial("tcp", "localhost:"+port)
try io.CopyN(os.Stdout, con, length)

Aprendizado

Este código é definitivamente artificial, eu admito. Mas o que estou chegando é que, em geral, try como uma expressão não funciona bem em:

1. No meio de expressões lotadas que não precisam de muita verificação de erros
2. Instruções de várias linhas relativamente simples que exigem muita verificação de erros

No entanto, concordo com @ianlancetaylor que iniciar cada linha com try parece atrapalhar a parte importante de cada instrução (a variável que está sendo definida ou a função que está sendo executada). No entanto, acho que, por estar no mesmo local e ter uma largura fixa, é muito mais fácil encobrir, enquanto ainda notamos. No entanto, os olhos de todos são diferentes.

Eu também acho que encorajar one-liners inteligentes no código é apenas uma má ideia em geral. Estou surpreso que eu possa criar uma linha tão poderosa como no meu primeiro exemplo, é um trecho que merece sua própria função porque está fazendo muito - mas se encaixa em uma linha se eu não o tivesse recolhido para múltiplo por questões de legibilidade. Tudo em uma linha:

fullContents := try(io.CopyN(os.Stdout, try(net.Dial("tcp", "localhost:"+try(r.ReadString("\n"))), try(strconv.Atoi(try(r.ReadString("\n"))))))

Ele lê uma porta de um *bufio.Reader , inicia uma conexão TCP e copia um número de bytes especificados pelo mesmo *bufio.Reader para stdout . Todos com tratamento de erros. Para uma linguagem com convenções de codificação tão rígidas, acho que isso nem deveria ser permitido. Acho que gofmt poderia ajudar com isso, no entanto.

Para uma linguagem com convenções de codificação tão rígidas, acho que isso nem deveria ser permitido.

É possível escrever código abominável em Go. É até possível formatá-lo terrivelmente; existem apenas normas e ferramentas fortes contra isso. Go ainda tem goto .

Durante as revisões de código, às vezes peço às pessoas que dividam expressões complicadas em várias instruções, com nomes intermediários úteis. Eu faria algo semelhante para try s profundamente aninhados, pelo mesmo motivo.

O que é tudo para dizer: não vamos nos esforçar muito para proibir códigos ruins, ao custo de distorcer a linguagem. Temos outros mecanismos para manter o código limpo que são mais adequados para algo que envolve fundamentalmente o julgamento humano caso a caso.

É possível escrever código abominável em Go. É até possível formatá-lo terrivelmente; existem apenas normas e ferramentas fortes contra isso. Vai mesmo tem que.

Durante as revisões de código, às vezes peço às pessoas que dividam expressões complicadas em várias instruções, com nomes intermediários úteis. Eu faria algo semelhante para tentativas profundamente aninhadas, pelo mesmo motivo.

O que é tudo para dizer: não vamos nos esforçar muito para proibir códigos ruins, ao custo de distorcer a linguagem. Temos outros mecanismos para manter o código limpo que são mais adequados para algo que envolve fundamentalmente o julgamento humano caso a caso.