Eating Exceptions

Question

Я анализирую файл с данными MalFormed время от времени.

и ы бросать исключение,

я хотел бы восстановиться после исключения и игнорировать плохие отформатированные данные.

Каков наилучший способ для этого?

try{ 
// parse file 
}catch(Exception){ 
//eat it. 
} 

* EDIT: * Я думаю, что мой вопрос не был хорошо понимал. Я хотел бы восстановить из исключения, любое исключение в этом отношении, я не хочу, чтобы моя программа остановилась. но продолжать.

Answer 1

Я думаю, что вы спрашиваете, это:

При разборе файла построчно, иногда текущая строка имеет неверные данные, которые вызывает исключение в код. Возможно, вам просто нужно структурировать свой код таким образом, чтобы try/catch окружал только синтаксический код, а не код чтения строки. Например:

using System; 
using System.IO; 
using System.Windows.Forms; 

public void ParseFile(string filepath) 
{ 
    TextReader reader = null; 

    try 
    { 
     reader = new StreamReader(filepath); 

     string line = reader.ReadLine(); 
     while (!string.IsNullOrEmpty(line)) 
     { 
      try 
      { 
       // parse line here; if line is malformed, 
       // general exception will be caught and ignored 
       // and we move on to the next line 
      } 
      catch (Exception) 
      { 
       // recommended to at least log the malformed 
       // line at this point 
      } 

      line = reader.ReadLine(); 
     } 
    } 
    catch (Exception ex) 
    { 
     throw new Exception("Exception when trying to open or parse file", ex); 
    } 
    finally 
    { 
     if (reader != null) 
     { 
      reader.Close(); 
      reader.Dispose(); 
     } 
     reader = null; 
    } 
} 

Внешняя попытка/поймать блок для обработки закрытия объекта чтения должным образом, если что-то произошло при попытке открыть или прочитать файл. Внутренний блок try/catch состоит в проглатывании исключений, возникающих, если считываемые данные искажены и не могут быть правильно проанализированы.

Я согласен с почти всем остальным. Просто глотать исключение может быть не очень хорошо. По крайней мере, я рекомендую вам зарегистрировать его где-нибудь.

Answer 2

try{ 
    // parse file 
    } 
    catch(Exception){ 
    //eat it. 
    } 
    finally 
    { 
     //cleanup must ... release system resources here (e.g. stream.Close() etc) 
     // code here always executes...even if the exception is unhandled 

    } 

// code will resume execution from this point onwards... 

Answer 3

Это работает - может быть, вы могли бы войти ошибки, хотя тоже в случае, если вы хотели посмотреть, что данные, что вызвало исключение произойдет и использовать, чтобы улучшить вашу логику синтаксического анализа.

Answer 4

Короче говоря, вы, вероятно, не должны использовать исключения для этого. Что-то вроде TryParse, который возвращает false, намного эффективнее и легче восстанавливается. Обработка исключений - это немного тупой подход.

MSDN Guidance on Exception Handling

Answer 5

Существует несколько хороших фон информация здесь: Is there any valid reason to ever ignore a caught exception

Короткий ответ: исключения являются дорогостоящими, чтобы использовать таким образом. Если это вообще возможно, протестируйте входные данные перед отправкой их для обработки и игнорируйте их, а не игнорируйте исключения.

Также убедитесь, что вы не используете слишком широкую сеть и не имеете законных исключений, о которых вы, возможно, захотите узнать.

Answer 6

В общем, что-то вроде этого:

try 
{ 
    // parse file 
} 
catch (FormatException) 
{ 
    // handle the exception 
} 
finally 
{ 
    // this block is always executed 
} 

Вы должны избегать ловель общих Exception дел и вместо того, чтобы поймать конкретное исключение, что бы это ни было.

Answer 7

Поймать общее исключение - плохая идея, если вы ожидаете, что он будет генерировать только один или два конкретных типа исключения для ошибок, связанных с синтаксическим разбором. Обычно лучше поймать каждый конкретный тип исключения и обрабатывать его независимо, чтобы ваш код не подавлял какую-либо другую (возможно, непредвиденную) ошибку (например, если файл отсутствует или время подключения к сети, следует ли его обрабатывать в точно так же, как если бы файл содержал поврежденные данные?)

Однако уловка общего исключения - отличная идея, если вы намеренно нуждаетесь/хотите поймать все возможные ошибки и изящно продолжать. Это может произойти, если обработка всех типов ошибок одинакова (например, «если по какой-либо причине я не могу прочитать это значение предпочтения, я верну его значение по умолчанию 5» - это бесконечно лучше, чем сбой вашей программы, потому что вы не " t понимают, что это может вызвать исключение из-за сетевого таймаута). Если использовать разумно, этот подход может сделать вашу программу пуленепробиваемой, но если ее использовать неразумно, вы можете подавить ошибки, о которых вам нужно знать и исправить, и это может быть очень болезненным.

При подавлении любых исключений вы всегда должны внимательно относиться к сообщениям об ошибках - должны ли вы сообщить пользователю, что у вас возникла проблема? Если вы зарегистрируете его в файле трассировки, чтобы, когда клиент жалуется на что-то, что не работает правильно, вы можете вернуться к источнику проблемы? Или вы должны молча игнорировать его?Просто будьте осторожны, так как чрезмерно усердные подавления могут затруднить работу прогамы, которая непредсказуемо ведет себя.

Answer 8

У меня возникает ощущение, что вы видите такие вещи, как черный & белый, и это не очень хорошо .. Да, в большинстве случаев нехорошо поймать все и быть неряшливым, когда дело доходит до проверки ввода, но не всегда. Это может быть особый случай. Я ничего не знаю о том, какие файлы будут разбираться, но исключения могут быть правильными.

Перед тем, как решить, что лучше, дайте нам более подробно :)