none
On error resume next RRS feed

  • Pergunta

  • Ola.

    Pessoal tenho uma dúvida.
    Temos agora o VB.NET a estrutura Try Catch. Devo parar de usar On Error Resume Next?

    Elton de Lima Ribeiro
    quarta-feira, 19 de agosto de 2009 14:26

Respostas

  • Antigamente o VB operava com Err (código de erro) Error (mensagem de erro) e Erl (linha do erro).
    Assim, se você quisesse saber o que aconteceu, poderia fazer um If Erl = 13 Then... (creio que 13 seja Type Mismatch).

    Hoje em dia as coisas evoluiram, mas o Err, Error e Erl são mantidos por compatibilidade. Erl não funciona mais, sempre retorna 0. Err.Raise(0) lança uma exceção System.InvalidOperationException, que é o código da exceção do 0.

    Para evitar confusão, jogue fora o Err, o Error e o Erl.

    Para Err.Raise use Throw New Exception("Mensagem") ou escolha uma exceção apropriada (tem várias, como New NotImplementedException, etc... ). A "padrão" é Exception.

    Para Error, use no catch o Exception.Message

    Para Erl, use no catch o Exception.StackTrace

    Evite usar os outros, exceto On Error Resume Next e On Error Goto 0, pois não existe outra forma de se ignorar todos os erros dentro de um escopo usando só .Net.

    Mas, dentro do possível, use o padrão, que é Try Catch e, principalmente, NUNCA deixe o aplicativo cair num Try Catch... Ë muito mais rápido um IF para evitar um erro qualquer do que o framework tratar uma exceção assim.

    Alan
    quarta-feira, 19 de agosto de 2009 14:33
  • Além do que os colegas já explicaram, através de uma execption você tem muito mais controle e informação a respeito do erro, pode encapsular outras exception, navegar pelo stack (innerexception), ter exceptions específicas tais como SqlException que mostra deltalhes do erro SQL que você não teria de outra forma, enfim, só tem vantagens em relação a forma antiga.

    Quanto a ser lento, não é algo que influencie na maioria dos aplicativos, a não ser os de missão crítica, o que é lento é o fato de você usar exception para controlar o fluxo, ou seja, disparar exception (throw new Exception...) e não o Try Catch em si. Pode faze um teste e verá é imperceptível.

    blog: http://lblima.blogspot.com twitter: http://twitter.com/lblima
    quarta-feira, 19 de agosto de 2009 15:58
    Moderador

Todas as Respostas

  • Com toda certeza.

    blog: http://lblima.blogspot.com twitter: http://twitter.com/lblima
    quarta-feira, 19 de agosto de 2009 14:28
    Moderador
  • Por que?
    Elton de Lima Ribeiro
    quarta-feira, 19 de agosto de 2009 14:29
  • Antigamente o VB operava com Err (código de erro) Error (mensagem de erro) e Erl (linha do erro).
    Assim, se você quisesse saber o que aconteceu, poderia fazer um If Erl = 13 Then... (creio que 13 seja Type Mismatch).

    Hoje em dia as coisas evoluiram, mas o Err, Error e Erl são mantidos por compatibilidade. Erl não funciona mais, sempre retorna 0. Err.Raise(0) lança uma exceção System.InvalidOperationException, que é o código da exceção do 0.

    Para evitar confusão, jogue fora o Err, o Error e o Erl.

    Para Err.Raise use Throw New Exception("Mensagem") ou escolha uma exceção apropriada (tem várias, como New NotImplementedException, etc... ). A "padrão" é Exception.

    Para Error, use no catch o Exception.Message

    Para Erl, use no catch o Exception.StackTrace

    Evite usar os outros, exceto On Error Resume Next e On Error Goto 0, pois não existe outra forma de se ignorar todos os erros dentro de um escopo usando só .Net.

    Mas, dentro do possível, use o padrão, que é Try Catch e, principalmente, NUNCA deixe o aplicativo cair num Try Catch... Ë muito mais rápido um IF para evitar um erro qualquer do que o framework tratar uma exceção assim.

    Alan
    quarta-feira, 19 de agosto de 2009 14:33
  • "Mas, dentro do possível, use o padrão, que é Try Catch e, principalmente, NUNCA deixe o aplicativo cair num Try Catch... Ë muito mais rápido um IF para evitar um erro qualquer do que o framework tratar uma exceção assim."

    Alan Cossari

    Justamente. Sei que o Try Catch é mais lento e devo evitá-lo quando possível.
    Não há outra maneira de usar o On Error Resume Next de uma forma mais "avançada" sem ter de inicar um Try Catch?

    Elton de Lima Ribeiro
    quarta-feira, 19 de agosto de 2009 14:38
  • Elton,

    O try, catch é a novo mecanismo do .NET Framework construido para detectar erros gerados pelo codigo escrito em sua aplicação.
    Essa estrutura ajuda o desenvolvedor a customizar mensagens de erros bem como identificar e informar erros decorrentes de programação.
    Na implementação do Try catch você pode mostrar ou não o erro que foi gerado, ou até mostrar em qual arquivo e linha que o correu o erro.
    Nesse exemplo vamos atribuir a V um texto isso fará com que o compilador execute uma excessão e quero que ele me informe em que arquivo e linha isso ocorreu.
    Public Shared Sub Main()
    Dim x As Integer = 0
    Dim v As String
    Try
    x=v
    Catch Ex As Exception
    'Aqui você define se mostra ou não o Erro gerado
    MessageBox.Show(ex.StackTrace)
    Finally
    msgBox("Fim da Execução")
    End Try
    End Sub 'Main
    Nesse outro codigo simplismente não quero que ele me informe se ocorrer o erro.
    Public Shared Sub
    Main()
    Dim x As Integer
    = 0
    Dim v As String

    Try
    x=v
    Catch Ex As
    Exception
    'Aqui você define se mostra ou não o Erro gerado
    'MessageBox.Show(ex.StackTrace)
    Finally
    msgBox("Fim da Execução")
    End Try
    End Sub 'Main

    Espero que ajude!
    Abraço!



    Robson Souza
    • Sugerido como Resposta Alan Cossari quarta-feira, 19 de agosto de 2009 17:46
    quarta-feira, 19 de agosto de 2009 15:12
  • Além do que os colegas já explicaram, através de uma execption você tem muito mais controle e informação a respeito do erro, pode encapsular outras exception, navegar pelo stack (innerexception), ter exceptions específicas tais como SqlException que mostra deltalhes do erro SQL que você não teria de outra forma, enfim, só tem vantagens em relação a forma antiga.

    Quanto a ser lento, não é algo que influencie na maioria dos aplicativos, a não ser os de missão crítica, o que é lento é o fato de você usar exception para controlar o fluxo, ou seja, disparar exception (throw new Exception...) e não o Try Catch em si. Pode faze um teste e verá é imperceptível.

    blog: http://lblima.blogspot.com twitter: http://twitter.com/lblima
    quarta-feira, 19 de agosto de 2009 15:58
    Moderador