Erro conceitual de try catch
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?
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?
Carlos Nogueira
Curtidas 0
Respostas
Fabio Mans
15/11/2009
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?
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?
GOSTEI 0
Carlos Nogueira
15/11/2009
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 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!
GOSTEI 0
Fabio Mans
15/11/2009
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!
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!
GOSTEI 0
Carlos Nogueira
15/11/2009
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!
Bem, no mais então seria só isso. Se desejar, pode finalizar este post!
Obrigado!
GOSTEI 0