Содержание
Про глобальный обработчик исключений
Про подавление исключений
Про общий try-catch блок
Про отладочные сообщения
Про более полное использование возможностей LINQ и C#
Про именование классов и переменных

  • Про глобальный обработчик исключений
см. статью на msdn AppDomain.UnhandledException

  • Про подавление исключений
В следующем фрагменте кода:
object createSomeObject()
{
    try
    {
        // ...
        return new Object();
    }
    catch (Exception e)
    {
        Console.WriteLine("log message");
        return null;
    }    
}
Можно выделить такие ошибки:
  • во-первых, возвращая null в обработчике исключений, вы фактически лишаете программу обработки исключительных ситуаций, т.к. вызывающий метод никаким образом не узнает, что в вызываемом им коде возникло исключение, и соответственно не сможет его обработать.
  • во-вторых, отлавливая наиболее общее исключение System.Exception, вы ловите также и всевозможные системные исключения.
В общем случае пользуйтесь правилами:
  • отлавливать только известные вам исключения. Все остальные пропускайте дальше.
  • подавлять только те исключительные ситуации, которые вы можете исправить.
Т.о. приведенный выше код можно было бы переписать, например, так:
try
{
    // ...
}
catch (Exception e)
{
    Console.WriteLine("log message");
    throw; // пробрасываем исключение дальше
}

  • Про общий try-catch блок
Не используйте один обработчик исключений на большой фрагмент кода, в котором могут произойти различные исключительные ситуации. Разбивайте код на логически независимые регионы о обрабатывайте исключения независимо. Т.е. вместо
try
{
    #region file reader
    // ...
    #endregion
    #region linq-based parser
    // ...
    #endregion
}
catch(...)
{
}
Пишите
try
{
    #region file reader
    // ...
    #endregion
}
catch(...)
{
}

try
{
    #region linq-based parser
    // ...
    #endregion
}
catch(...)
{
}

  • Про отладочные сообщения
Вместо такого кода:
Console.WriteLine("log message");
Лучше писать так:
#if DEBUG
logger.write("log message"); // logger - экземпляр класса логгера
#endif
Это, во-первых, позволит явно выделить отладочный код, который будет исключаться из релизной версии. Во-вторых, использование специального объекта-логгера вместо простого вывода на экран улучшает расширяемость отладочных действий.

  • Про более полное использование возможностей LINQ и C#
Вместо
string[] someList = {"1","2","3","4"};
IEnumerable<String> q = from p in someList where p.Length < 3 select p;
foreach (var item in q)
{
    Console.WriteLine(item[0]);
}
Лучше писать:
var q = from p in someList where p.Length < 3 select p[0];
foreach (var item in q)
{
    Console.WriteLine(item);
}
Вывод типов С# позволяет сократить код. А разделение кода на парсерный и код вывода на экран делает исходник более читаемым.

  • Про именование классов и переменных
Не называйте класс, производящий разбор XML файла заданной структуры - "XML". Это слишком общее название, не отражающее функций описываемого класса. Давайте название типа XMLEventsParser.


Last edited Mar 20, 2012 at 10:25 AM by basph, version 16

Comments

No comments yet.