Fórum Erro conceitual de try catch #11639

Olá eu não entendi a pergunta qual o erro Conceitual? O que sabemos sobre o conceito de erros é que devemos tratar do mais específico para o mais genérico e no seu exemplo temos somente o erro genérico, mas pode ser que no métodos GetAllProducts ele trate o erro de SQLException. Vou deixar um link que acho muito bom falando sobre erros. http://unplugged.giggio.net/unplugged/post/Como-tratar-erros.aspx Aguardo sua pergunta   Fabio       ============================================================ Oi!

Esses dias atrás fui fazer uma entrevista e no teste relacionado a teoria caiu o exemplo de código similar ao que vou colocar abaixo:

try
{
      GridView1.DataSource = produtos.GetAllProducts();
      GridView1.DataBind()
}
catch (Exception ex)
{
      // implementação do tratamento de exceção
}

Foi questionado para este exemplo, qual era o erro conceitual do bloco de código que coloquei acima. Dei uma pesquisada na internet, e encontrei algo superficial de um cara que postou na net ao dizer que ele pegou o erro por meio da classe Exception. O que deu a entender é tentar fazer tratamento de erros com base na classe Exception.

Caso queiram visualizar o que a pessoa havia escrito, o link é esse: http://infoblogs.com.br/view.action?contentId=189270&Servicos-do-Grails-Transacoes-e-Rollback-automatico.html

A minha dúvida é: existe algum erro conceitual que envolve o tratamento de exceções, como exemplo o bloco de código informado logo acima?

Olá Fábio!

Eu li seu post, realmente o artigo do Giovanni é muito interessante. Após ler o artigo, percebi que cometo algumas gafes no tratamento de exceção, por exemplo, eu aplico no tratamento de exceções, no bloco no catch o "thrown ex;" para jogar a exceção para quem a chamou, e lá, ou as vezes fazia do mais especifico para o mais generico, ou lançava uma mensagem de erro generica.

Quanto ao log de erros, concordo plenamento com o Giovanni.

O erro conceitual que comentei no post deste suporte deve ser justamente em relação a isso, usar somente o System.Exception para o tratamento de exceções e a falta de cuidado para analisar as exceções que podem acontecer (fazer do mais especifico para o mais generico).

Agora, tem algumas coisas no artigo dele que gostaria de comentar contigo, porque não entendi. Ele comenta em alguns pontos, que o pessoal usa o try, catch, finally em todo o código e isso não deveria acontecer, e fez exemplo do comentário dele em relação a instanciar um objeto de uma classe. Mas, até onde entendi, e se eu não estiver enganado, a própria Microsoft fala que com exceção de variáveis do tipo valor, o resto deve ser colocado dentro de um tratamento de exceção. O que você pensa a respeito disso?

E outro ponto que ele comentou, que ele citou o exemplo do CPF inválido, não lançar uma exceção por causa disso e sim retornar um objeto ou outra coisa do tipo, pois isso é uma condição que o sistema tem que atender, e não é uma exceção. Mas em um dos cursos que vi aqui na DevMedia do Guinther Pauli sobre exemplo de desenvolvimento de projetos em camadas (camada mais simples, interface, negócio e persistência) o próprio menciona que você pode lançar exceções para esse tipo de situação (CPF inválido).
O que você pensa a respeito disso?

Ah, escrevi escrevi e escrevi, e nem te agradeci pelo envio do artigo. Obrigado mesmo!

Fico no aguardo!

Eu não uso em todo o código, somente onde vejo que possa ocorrer o erro realmente, um exemplo comum é o pessoal utilizar em todos os métodos de uma DAL eu evito, sabe porque? try catch ajuda mas tem problema de performance, e vale a dica do Giovanni sempre temos que avaliar se precisa ou não utilizar.   Sobre o CPF eu acho correto, concorda que não é um erro?   Fabio   ======================================================== Olá Fábio!

Eu li seu post, realmente o artigo do Giovanni é muito interessante. Após ler o artigo, percebi que cometo algumas gafes no tratamento de exceção, por exemplo, eu aplico no tratamento de exceções, no bloco no catch o "thrown ex;" para jogar a exceção para quem a chamou, e lá, ou as vezes fazia do mais especifico para o mais generico, ou lançava uma mensagem de erro generica.

Quanto ao log de erros, concordo plenamento com o Giovanni.

O erro conceitual que comentei no post deste suporte deve ser justamente em relação a isso, usar somente o System.Exception para o tratamento de exceções e a falta de cuidado para analisar as exceções que podem acontecer (fazer do mais especifico para o mais generico).

Agora, tem algumas coisas no artigo dele que gostaria de comentar contigo, porque não entendi. Ele comenta em alguns pontos, que o pessoal usa o try, catch, finally em todo o código e isso não deveria acontecer, e fez exemplo do comentário dele em relação a instanciar um objeto de uma classe. Mas, até onde entendi, e se eu não estiver enganado, a própria Microsoft fala que com exceção de variáveis do tipo valor, o resto deve ser colocado dentro de um tratamento de exceção. O que você pensa a respeito disso?

E outro ponto que ele comentou, que ele citou o exemplo do CPF inválido, não lançar uma exceção por causa disso e sim retornar um objeto ou outra coisa do tipo, pois isso é uma condição que o sistema tem que atender, e não é uma exceção. Mas em um dos cursos que vi aqui na DevMedia do Guinther Pauli sobre exemplo de desenvolvimento de projetos em camadas (camada mais simples, interface, negócio e persistência) o próprio menciona que você pode lançar exceções para esse tipo de situação (CPF inválido).
O que você pensa a respeito disso?

Ah, escrevi escrevi e escrevi, e nem te agradeci pelo envio do artigo. Obrigado mesmo!

Fico no aguardo!

Concordo plenamente com você, inclusive antes quando existia mensagens para esse tipo de validação, eu tinha uma propriedade string que alimentava com essas informações para depois exibir para o usuário. Depois que vi o vídeo do Guinther Pauli que eu mudei a forma de tratar essas regras e era justamente o que queria saber de você a respeito, já que obtive opinições diferentes sobre mesmo assunto (Guinther Pauli e Giovanni).

Bem, no mais então seria só isso. Se desejar, pode finalizar este post!

Obrigado!