Exception-ы и мифы о них

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

Помните, как надо бороться со страхом? Засекаешь одну минуту, в течение которой даешь волю всем своим эмоциям. Затем говоришь себе «хватит» и с головой погружаешься в проблемы. Минута прошла.

Для начала давайте выясним, а что же это за зверь такой. Я выделяю следующие свойства:
  • невозможно игнорировать наступление;
  • несколько обработчиков в одном месте;
  • просачивание через любое количество вложенных вызовов;
  • независимая, передаваемая обработчику, структура данных — вспомните hresult, макросы вызова com-фунций и другую белиберду, обязанную своим существованием отсутствию (или нежеланию использовать) механизмов exception-ов

И все. Всевозможные потери в производительности, сложность контроля являются контекстно-зависимыми (а чаще просто надуманными) и требуют доказательства в каждом конкретном случае.

Например: производим поиск по файлу.

int FindSymbol(TextReader reader, char symb)
{
  char cur;
  int pos;
  while (cur = (char)reader.Read())
  {
    if (cur == ‘a’)
      throw new FormatException();
    pos ++;
    if (cur == symb)
      return pos;
  }
  throw new MyException(); }
}



Определены следующие варианты выхода из функции:
  • требуемые данные найдены (return pos)
  • файл имеет не правильный формат (throw)
  • файл закончился (reader поднимает исключение)

Последний вариант работы функции наиболее спорен. Обычно программисты очень изобретательны при обосновании своих решений, и могут найти кучу доводов «за» и «против»: неэффективность, клиентскому коду необходимо знать детали реализации, неправильный формат является ошибкой и т.д. Все это правда, но не главное. Основной довод «за» — достаточность.

Клиенту больше не надо анализировать сложный результат, он попросил найти текст — ему нашли; если нет — он об этом даже не узнает.

Еще пример: обработка нажатия пользователем кнопки «cancel». Опять же можно долго дискутировать на тему — для чего изначально создавался этот механизм?

Но если он есть и подходит для логики «cancel» — глупо его не использовать.
Когда мне нужно было подклеить дома порожек, я, недолго думая, использовал в качестве груза книгу М.Мак-Дональда «Wpf …». Так почему же в иных случаях мне поступать иначе?

Как вы относитесь к маленьким функциям? Я вот считаю, что другие просто не имеют права на существование. При таком отношении периодически возникают ситуации, что без поднятия исключений просто никуда. Например, надо выйти из цикла, расположенного выше по стеку вызовов. Не передавать же флаг завершения, в конце концов. Или передать…
Если же цикл располагается не на предыдущем уровне стека вызовов, а выше? Весь код без throw превращается в анализ результатов работы функций. Доходит до смешного — выделяются методы проверяющие результаты работы других функций. Сидишь и думаешь об откате неожиданно «неправильного» рефакторинга. Но все меняется, когда приходят они: код начинает удаляться по две-три строчки за раз (а если я тормозил
до этого достаточно долго, то удаляются и методы, и классы)

А вот еще один интересный «аромат» — большое количество условных операторов. Когда перед выполнением какого-либо действия начинается анализ, «а можно ли это сделать». Оставим в покое алгоритмы, состоящие из нескольких операций, которые по отдельности делают состояние системы неопределенным. Если начал делать, — разбейся в лепешку, но закончи! Я не про них. Хотя и здесь, при желании, можно найти приемлемые решения. Так вот, запах от большего количества условных операторов: ну например, при анализе набора входных данных перед выполнением операции или проверка валидности структуры данных, или… ну мало ли чего еще. В общем, смотрим на каждый элемент данных и решаем, а подходит ли он для наших великих целей, а затем осуществляем их. Не глупо ли? Можно же сразу попробовать осуществить задуманное. И всего-то надо — предположить, что на данном участке может произойти исключение, связанное с нашим нежеланием загромождать код мусором.

Основным аргументом у противников такого отношения к подъему исключений является просадка производительности. Глупо с этим спорить — условный оператор в несколько раз более эффективен. Но есть одно «но»: проблему надо доказать на реальных данных. Предположим, участок кода действительно критический. О ужас! — теперь придется потратить пару часов на рефакторинг. Не дней, а именно часов. Помните как рассказывал Фаулер о своем отношении к проектированию: «…я пытаюсь определить, насколько трудно окажется рефакторинг от одного дизайна в другой. Если трудностей не видно, то я, не слишком задумываясь о выборе, останавливаюсь на самом простом».

Если предположить, что мы принимаем эту смелую мысль, то осталось определиться с порядком рефакторинга:
  1. Выделяем метод из тела метода поднимающего исключение.
  2. Определяем критерий в сигнатуре выделенного метода, который будет показывать, что в иной ситуации мы бы подняли исключение.
  3. Изменяем исходный метод таким образом, чтобы он, в зависимости от критерия, поднимал исключение. Будем называть исходный метод «методом с исключением», а выделенный — «метод без исключения».
  4. Создаем метод расширение (копированием) из метода без исключения.
  5. Заменяем тело метода расширения на вызов метода с исключением.
  6. Блокируем распространение исключения через метод расширения и, в зависимости от подъема, взводим или сбрасываем критерий.
  7. Добавляем к интерфейсу метод с сигнатурой метода без исключения. В реализациях этих методов производим вызов метода расширения. Если метод не входит в состав внешнего интерфейса (по отношению к классу) — тем лучше. Этот пункт можно пропустить.
  8. Заменяем вызовы метода с исключениями методами без исключения. В реализациях интерфейса это обязательно (иначе не следовало и начинать), в остальных случаях — по желанию. Замещающий код должен выглядеть так: вызов метода без исключения, анализ критерия.
  9. Создаем метод расширения из метода с исключением. Структура его должна уже быть верной. Осталось только сделать его рабочим.
  10. Заменяем оставшиеся вызововы с исключениями на расширения без исключения.
  11. Удаляем из интерфейса методы с исключениями и расширения без исключения. Расширения с исключениями по возможности.


Вот как это будет выглядеть в коде.
  • Исходный код:
    class SrcClass
    {
      public void Exec()
      {
        throw new MyException();
      }
    }
  • После третьего шага:
    class SrcClass
    {
      public void Exec()
      {
        if (!TryExec())
          throw new MyException();
      }
      public bool TryExec()
      {
       return false;
      }
    }
  • После девятого шага:
    class SrcClass
    {
      public void Exec()
      {
        if (!TryExec())
          throw new MyException();
      }
      public bool TryExec()
      {
        return false;
      }
    }

    static class SrcClassHelper
    {
      public static bool TryExecHelp(this SrcClass src)
      {
        try
        {
          src.Exec();
          return true;
        }
        catch (MyException)
        {
          return false;
        }
      }
      public static void Exec(this SrcClass src)
      {
        if (!src.TryExec())
          throw new MyException();
      }
    }
  • По завершению:
    class SrcClass
    {
      public bool TryExec()
      {
        return false;
      }
    }

    static class SrcClassHelper
    {
      public static void Exec(this SrcClass src)
      {
        if (!src.TryExec())
          throw new MyException();
      }
    }


В принципе все. Надеюсь, я сумел развеять хотя бы часть страхов о подъеме исключений, и теперь при возникновении такой необходимости вы более лояльно будете выбирать решение. И скорее всего, выберите более простое. А значит, ваш приемник будет ругать вас с меньшим остервенением (не исключено что им буду я).

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 68

    +2
    Неплохая старт-статья. В принципе, всё так, хотя и не заметил чего-то нового для себя.

    Правда, я совсем не понял того, что написано про рефакторинг. Может стоит также изобразить на примере?
      0
      Изначально рефакторинг писался как перекрытие спины: если что — всегда можно перейти к коду без исключений. 11 пунктов писал с большой не охотой — потому что сам только мельком бы просмотрел. Мой основной аргумент: примеры для рефакторингов не полные и громоздкие. Но вы второй задавший этот вопрос (первый online), а потому сомнения исчезли — пример написан. Как только пойму, как не выводя статью из обсуждения ее исправить, так сразу.
      +3
      Надо новый термин ввести — throwФобия.
      Примеров кода действительно не хватает, описание рефакторинга не очень читаемое.
        0
        throwФобия

        Вообще часто чем меньше исключений и чем более они локазилованы — тем лучше.
        Пример — можно написать класс, выполняющий какие либо вычисления и принимающего в конструктор путь к файлу/поток для записи результата.
        А можно сделать так, чтобы этот класс возвращал объект результата, и написать форматтер, который будет этот объект результата писать в поток.
        Во втором случае все исключения, завязанные на доступ к внешнему ресурсу для сохранения — выделяются в отдельный класс, и стабильность системы повышается.
          +1
          У вас речь о разделении обязанностей. Какое это имеет отношение к исключениям?
            0
            Прямое отношение, исключения должны выбрасываться по возможности только там, где на пути по стеку они не уничтожат работу, которая не зависит от причины возникновения исключения.
              +6
              Простите, что? То есть метод, выбрасывающий исключения, должен внутри себя предполагать, как выглядит стек трейс до входа в него? Для публичных методов это сильно пахнет нарушением инкапсуляции.

              Ситуация должна быть обратной — в документации к методам обычно пишется, какие исключения он выбрасывает, и вызывающий код должен позаботиться об обработке этих исключений.
                0
                Все верно, если разделить ответственность на все классы, чьи методы вызваются по стеку. Класс, выкидывающий изначально исключение — знает, какая часть проделанной работы будет уничтожена, и будет ли повреждено состояние класса. Класс выше знает, что вызывает метод, потенциально выкидывающий исключение — он должен тоже самое предполагать о своей работе и своем состоянии.
                  0
                  Да! В этом и проблема, что должен.

                  Например в Java компилятор может проверить, что произведён перехват с помощью catch, но не может проверить, его корректность или наличие корректного finally. В С# ситуация такая же AFAIK.
          +6
          Мне сразу вспомнились холиварные статьи о goto. Здесь точно так же не хватает реальных примеров, где throw делает жизнь заметно легче.

          Лично я не считаю, что в процессе нормальной работы программы должны возникать какие-либо исключения. В конце концов — подумайте о коллегах. Вы сделаете отладку кошмаром. Даже если отключить break on exceptions, debug output будет захламлён, и полезная информация исчезнет из виду.

          Exceptions, Исключения — на то они так и называются. Возникают в исключительных ситуациях.
            0
            Даешь переход от trow-фобии к throw-филии!
              –1
              foreach(string element in elements)
              {
                  try
                  {
                      int someData = int.Parse(element);
                      result.Add(someData);
                  }
                  catch
                  {
                  }
              }
              

              Не совсем throw-филия, но вполне себе exception-филия.
                +1
                Для этого есть TryParse
                foreach (var element in elements)
                {
                int someData;
                if (int.TryParse(element, out someData))
                result.Add(someData);
                }


                Можно в две строчки, но неэффективно:
                int i;
                var result1 = elements.Where(e => int.TryParse(e, out i)).Select(e => int.Parse(e));

                Жаль, что нету метода int? Parse(s), который возвращает null в случае неудачи. Но что-то я увлёкся.
                  +1
                  Так я это и имею ввиду, что надо писать TryParse, а вышеприведенный мной код — пример throw(exception)-филии.
                    0
                    Если уж писать в одну строчку — то лучше сделать для этого заранее Extension:
                         var result = DataFilter.Filter<string, int>(sourceData, int.TryParse);
                    

                        public delegate bool TryParse<in TInput, TOutput>(TInput input, out TOutput output);
                    
                        public static class DataFilter
                        {
                            public static IEnumerable<TResult> Filter<TSource, TResult>(IEnumerable<TSource> sourceSequence,
                                                                                        TryParse<TSource, TResult> tryParseFunction)
                            {
                                List<TResult> result = new List<TResult>();
                                foreach (var sourceElement in sourceSequence)
                                {
                                    TResult resultElement;
                                    if (tryParseFunction(sourceElement, out resultElement))
                                    {
                                        result.Add(resultElement);
                                    }
                                }
                    
                                return result;
                            }
                        }
                    
                      0
                      Тьфу, Helper заранее сделать, поздно уже.
                        0
                        А я бы таки сделал тот самый extension метод с Nullable:

                        var result = elements.Select(e => e.ToInt()).Where(e => e != null);

                        public static class StringExtensions
                        {
                        public static int? ToInt(this string s)
                        {
                        int i;
                        return int.TryParse(s, out i) ? i : (int?) null;
                        }
                        }



                        Более лаконично, и ленивое выполнение.
                          0
                          Тогда придется писать каждый раз новый экстеншн на каждый новый тип, в моем примере все что требуется — соблюдать сигнатуру метода TryParse, которую обычно везде соблюдают.
                          Ну и потом — много extension'ов — сильное захламление IntelliSense.
                      0
                      Ты собираешься парсить строку дважды??

                      я бы так сделал:

                      int i;
                      var result1 = elements.Where(e => int.TryParse(e, out i)).Select(e => i)

                      ну и можно замкнуть перечисление:

                      int i;
                      var result1 = elements.Where(e => int.TryParse(e, out i)).Select(e => i).ToList()
                        0
                        Во-первых, я отметил, что это неэффективно.
                        Во-вторых, твой код даже не скомпилируется. Недавно пользуешься linq и лямбдами?
                          0
                          Аха, давно. Вот так скомпилируется:

                          int i=0;
                          s.Where(e => int.TryParse(e, out i)).Select(e => i);
                  +2
                  Но если он есть и подходит для логики «cancel» — глупо его не использовать.

                  Если у меня есть дробовик, и он подходит для устранения очереди в банке — глупо его не использовать! Что может случиться плохого? Приедут дяди с мигалками и объяснят что так делать не хорошо, устранив вас из общества на много лет.

                  Подобно этому, если вы начнете вот так писать в крупном проекте, то придут злые дяди и устранят вас из этого проекта (а может и из компании) на много лет. И сидите там потом и хоть обдоказывайтесь и обспорьтесь о том, что дробовик — идеальное средство разгона очередей, потому что вместо какой-то там возни бабах — и все убежали. А то, что пара трупов? Да кого это волнует!
                    +6
                    Политика проверки по флагу:
                    — Дорогой, тебе нравится туалетная вода, которую я тебе купила?
                    — Нет.
                    — Ок, я сейчас что-нибудь придумаю.

                    Политика попытки сохранять целостное состояние:
                    — Дорогой, я купила тебе туалетную воду, пользуйся.
                    — Ок.

                    Политика исключений:
                    — Дорогой, я купила тебе туалетную воду, пользуйся.
                    *хватаясь за ремень* Ах ты ж стерва, я терпеть не могу такой аромат!

                    Как надо было сделать:
                    — Дорогой, какую туалетную воду ты любишь?
                    — %result%.
                    — Дорогой, я купила тебе туалетную воду %result%, пользуйся.


                      +7
                      В политике исключений вместе с туалетной водой безжалостно был уничтожен принесенный женой батон колбасы и случайно был подстрижен налысо оказавшийся рядом кот.
                        0
                        С чего бы? Это уже дело жены: решить уничтожить колбасу или нет. В политике исключений мы как раз отвязываемся от необходимости знать все стеки вызовов. Схватив неизвестное исключение на самом верхнем уровне, мы откатим все сделанные изменения, чтобы не нарушить целостность данных. Схватив на любом уровне известное исключение, мы уже решим по месту, уничтожить колбасу или просто сходить в магазин поменять туалетную воду.

                        «Как надо было сделать»:
                        — Дорогой, какую туалетную воду ты любишь?
                        — %result%.
                        … Прошло время…
                        — Дорогой, я купила тебе туалетную воду %result%, пользуйся.
                        — Да меня тошнит уже от неё
                        — О_о
                          0
                          Ну не совсем согласен. Все же обычно выкидывание исключения задевает и ту работу, которая могла не зависит от исключения. Откат к предыдущему стабильному состоянию как раз и подразумевает такое поведение. Ну а побритый кот — это например неосвобожденные блокировки и прочие вещи, которые находятся в некорректном состоянии из-за ошибки.
                            0
                            Для гарантированного освобождения ресурсов существуют специальные языковые конструкции: finaly, using. Возврат к стабильному состояния с их помощью внушает куда больше доверия, чем операции по else. А потом, если мы говорим об высвобождении ресурсов, их необходимо использовать в любом случае — ThreadAbortException или OutOfMemoryException ни кто не отменял. Если же писать и там и там — получим дублирование.
                              0
                              И вы, безусловно, можете гарантировать на этапе написания кода, что в нем не существует ни одного места, где из-за ошибки теряется блокировка или остается объект с поврежденным состоянием?
                              Использование исключений только там, где они действительно нужны, а не где они — один из способов — позволяет упростить программу, и следовательно — избежать ошибок (если только вы не научились программировать без ошибок с первого раза).

                              // В случае OutOfMemory обычно проще сохранить все что можно сохранить из текущего состояние программы и выйти.
                                0
                                Конечно могу.
                                Если я пишу:

                                using(new FileInfo("1.txt").OpenText())
                                  throw new MyException();


                                Я гарантировано освобождаю блокировку файла. Если нет — язык в топку.
                                Восстановление же фрагментов состояния в разных местах, на мой взгляд, разновидность запаха стрельба дробью (термин по Фаулеру).
                                  0
                                  Как же вы недальновидно пишете, как будто весь код — это те две строчки, которые вы написали, в сторонних библиотеках нет никаких ошибок, в другом коде тоже нет никаких ошибок.
                                  Так может вы и IDE не пользуетесь? С такими навыками «конечно могу» можно и в блокноте без ошибок писать. Я бы тоже хотел так, но к сожалению в реальном мире это невозможно.

                                  Ваш же пример и содержит ошибку, вы же должны знать, что using(statement) в C# в вашем случае эквивалентно:
                                  var textStream = new FileInfo("1.txt").OpenText();
                                  try
                                  {
                                      throw new MyException();
                                  }
                                  finally
                                  {
                                      if (textStream != null)
                                      {
                                          ((IDisposable)textStream).Dispose();
                                      }
                                  }
                                  Что делает его бесполезным. А в общем случае эксепшн может вылетить и до начала using.
                                    0
                                    Знаю, использую, не пишу.

                                    И что это меняет.
                                    Мы насколько я помню говорим о восстановлении состояния (и как частности: освобождение блокировок). А не о бескрайних полях синтаксического сахара C# и проверки результатов инициализации состояния.
                                    По поводу двух строк: я лишь предложил крайний случай закона Мерфи в минимальной реализации. Вы внимательно не анализировали их, а поняли меньше чем за секунду. Следовательно, цели с которой они написаны, достигнуты.
                                    Если же throw new… заменить на вызов «сторонних библиотек» как вы по сути предлагаете, то защищаемый мной подход даст гораздо больше гарантии не потерять стабильное состояние системы.
                                    С помощью if можно проверить результат на null-value, а предполагая возможность exception-ов можно реализовать откат работы, если точно не сказано что все OK — паттерн транзакция (http://insidecpp.ru/patterns/transaction/).
                                      0
                                      Ну во первых далеко не всегда возможно корректное освобождение состояния, т.к. может остаться висеть ссылка на объект, который что-то держит. В менее тривиальных ситуациях finally просто не получится написать, т.к. контекст не ограничен одним методом.
                                      Ну и все же я говорил к тому, что использование исключений надо минимизировать, а именно — чтобы через них не была реализована логика, чтобы исключение было ошибкой.
                                      0
                                      StreamReader textStream = null;
                                      try
                                      {
                                          textStream = new FileInfo("1.txt").OpenText()
                                          throw new MyException();
                                      }
                                      finally
                                      {
                                          if (textStream != null)
                                              ((IDisposable)textStream).Dispose();
                                      }
                                        0
                                        К чему этот комментарий? Мой ответ был о том, как разворачивается using, а как писать правильно этот код я знаю.
                                        А вообще даже этот код в некоторых случаях не освобождает блокировку файла, в случае таких опасных исключений как ThreadAbortException, или, например OutOfMemoryException. И если в последнем случае вообще надо бы быстрее закрывать программу сохраняя что есть, то если кто-то додумается прервать ваш поток, без проблем не отделаетесь.
                                          0
                                          Сорри, я думал разворачивается, как я написал, по крайней мере почему-то так отложилось. Проверил сейчас IL код, и действительно, у вас и в MSDN правильно написано ;-)
                      +3
                      Блин, при всём уважении к автору, прошу его: поправьте орфографию!
                        +3
                        разработчики гугла считают что исключения в C++ ведут к быдлокоду: google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions
                          0
                          Не правда. Они считают, что в их конкретной ситуации (уже куча кода написана без использования исключений) это неоправданно — об этом пишут в обсуждении темы.
                          0
                          > файл закончился (reader поднимает исключение)
                          В данном случае обычной практикой является возвратить значение -1, если символ не найден:

                          int FindSymbol(TextReader reader, char symb)

                          И вот почему:

                          for ( int i = findSymbol( r, 'a' ); i >= 0; i-- ) {
                          doSomethingWithTheseSymbols( i );
                          }

                          А исключения нужны именно для того, чтобы прервать всю цепочку вызовов и делегировать логику обработки функциям более высокого уровня.

                          P.S. тут недавно проходил обзор языка Go, и того извращения, которое они придумали вместо эксепшнов…
                            0
                            Самое неприятное при использовании исключений — это когда их забывают ловить. А ловить исключение, брошенное из другого потока — весёлое занятие. Ещё можно не ловить бросаемые исключения в конструкторах…
                              +1
                              Клиенту больше не надо анализировать сложный результат, он попросил найти текст — ему нашли; если нет — он об этом даже не узнает.

                              Конечно, анализировать ошибки это для неудачников. У реальных пацанов всё всегда OK… ну если не OK то по крайней мере хватает стали в яйцах сказать пользователю, что OK.
                                0
                                Где-то код анализа проблеммы находиться обязан. Но это место не обязано распологаться непосредственно под вызовом критического кода. Это приводит к размытию основоной идеи кода.
                                Что делает if(-1==reader.ReadByte()) — он пытается интерпритировать ответ. Зачем интерпретировать если можно получить точный, структурированный, расширяемый результат от первого лица?
                                В то же время ветка if, отвечающая за обработку нестандартных ситуаций в большинстве случаев заканчивается return null-Value (или аналогично — например break). Тем самым мы делегируем ответственность принятия решения о дальнейших действиях.
                                Оба механизма уже реаизованы: тип исключения точно описывает проблему, а просачивание позволяет определить место где действительно достаточо данных о принятии однозначного решения.
                                  0
                                  Он должен находиться не «где-то» а прямо тут. Потому-что прямо тут можно забыть закрыть открытый коннект к БД или обратиться к неинициализированной переменной с вываливанием другого исключения, превращающего поиск источника ошибки в детективный роман.

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

                                  Использование исключений упирается в талант и прозорливость архитектора системы. Они даже в теории ограничены ограничены. А на практике обычно архитектора вообще нет.
                              • UFO just landed and posted this here
                                • UFO just landed and posted this here
                                    –2
                                    30% это не так много. В любом случае факт просадки производительности из за Exception-ов должен определять profiler.

                                    Сваливание тестов во время рефакторинга, говорит о большой величине шага в процессе его осуществления. На достаточно хорошо покрытой тестами системе правильней откатиться и уменьшить шаг.
                                    А после: недостаточность набора тестов, по крайней мере проверяющих эти аспекты работы. Для теста не особо важно возвращает тестируемая логика null, ResWork.Fail или поднимает Exception — если существует проверка одного, то тест плавно превратится в другое.

                                    Мы же об автотестах?
                                    • UFO just landed and posted this here
                                        0
                                        Честно говоря, не хотел вас обидеть словами «правильно» и «не правильно». В первой редакции даже написал (там где о шаге) «в описываемой вами» — то есть отдавал должное факту наличия автотестов.

                                        Если не так все радужно, то здесь выход толко локализация шагов рефакторинга. И рефакторинг заменой кода на оттестированый. Сам мучуюсь.

                                        30%: из-за них я месяц назад не стал рисковать. У меня было 2 и 3 дня. Мне показалась что это цифры одного порядка. Хотя конечно каждая система уникальна.
                                        • UFO just landed and posted this here
                                    –1
                                    Этот подход очень неплохо показал себя в библиотеке boost.asio. Там для каждого действия введены 2 функции: одна с исключением, другая — без него. Для функции без исключения передается специальный параметр, который говорит о том, какая конкретно ошибка произошла. Таким образом можно использовать любой из подходов без потери производительности, а также их комбинировать. Но написание такой библиотеки — довольно хлопотное дело.
                                      +1
                                      Эксепшены тормозят выполнение раз в 10. Я тоже не верил пока не нарвался.
                                      К примеру откройте Visual Studio и выполните простой цикл, чтобы внутри него кидалось и обрабатывлось исключение.
                                      Затем выполните этот же цикл без блока try/catch.

                                      Лично у меня разница получилась в 10 раз, что там где есть исключение работает медленнее.

                                      Я повторюсь, что в это не верится, пока на практике не столкнешься, насколько они работу замедляют.
                                        0
                                        Я этого не отрицаю. Сталкивался.

                                        Но цикл с try catch внутри и обработка реальных данных — это не совсем одно и тоже. Повторюсь, факт просадки производительности может подтвердить только profiler. Только он может сказать что данный фрагмент выполняется достаточно часто, чтобы стать причиной проблем в работе системы вцелом.

                                        Например, внутри цикла шифрования я бы этого делать не стал, а для извещения о браке в ключе вполне.
                                          0
                                          Я столкнулся в ситуацией, когда мне надо было обработать около 1000 объектов из базы, и создать новые объекты, в каждом из котором где то 20 полей, то есть получается 20000 полей надо было обработать. И решил не заморачиваться с проверками на null, а просто обернуть в try/catch и возвращать пустую строку в случае null. Имеется ввиду не просто object.Property, а например object.anotherObject.anotherProperty, где каждый элемент может быть null. Получилась огромная просадкда производительности. С тех пор я убедился что эксепшены надо юзать осторожно.
                                            0
                                            К моменту получения информации о существовании проблемы вы уже разработали работающий функционал. Разработка окончена (по крайней мере на этом локальном участке кода на данной итерации). Устранение непрерывного потока exception-ов является задачей процесса профилирования, которую в подавляющем большинстве случаев решать не приходится.
                                          0
                                          В С++, насколько я слышал и наблюдал сам, оптимизируется не случай, когда исключение выбрасывается, а случай, когда оно не выбрасывается (т.н. zero-cost exception handling). Т.е. разработчики компилятора считают, что вы будете кидаться исключениями только в редких нештатных ситуациях.

                                          У себя тоже в «синтетическом» примере я наблюдал разницу где-то в 1-3%, которая в зависимости от поведения оптимизатора в компиляторе (без указания inline отказался автоматически инлайнить функцию с исключением) была в пользу исключений или в пользу возврата кода ошибки.
                                          +2
                                          Как вы относитесь к маленьким функциям? Я вот считаю, что другие просто не имеют права на существование. При таком отношении периодически возникают ситуации, что без поднятия исключений просто не куда. Например, надо выйти из цикла расположенного выше по стеку вызовов. Не передавать же флаг завершения, в конце концов. Или передать…


                                          Такое ощущение, что у вас единственный критерий декомпозиции кода на функции — это размер получаемых функций. В результате получается лапша-код с которым без бензопилы исключений не справиться. Ну вот пример: откуда функция знает, что её вызывают из цикла? Да какое вообще её дело из цикла ли её вызывают, или ещё откуда? Получаем: «Ты туда не ходи, ты сюда ходи, ексепшен башка упадет, совсем мертвый будешь».
                                          Функция должна быть самодостаточна, иметь хороший идентификатор и сигнатуру, по которой программист может понять где и как этой функцией можно и нужно пользоваться даже без заглядывания в её код. Исключения же делают интерфейс функции неявным. Программисту теперь мало посмотреть на сигнатуру, ему еще надо изучить код, чтобы понять в каких случаях какие исключения выкидываются. Это не проблема когда код был написан недавно и программист помнит это наизусть, либо когда код пишется на выброс. Но вот дальнейшая поддержка сильно усложняется.
                                            –1
                                            Анализируя типичный rant по поводу того, какие исключения плохие, я выяснил, что многие их просто не умеют готовить. Не понимают, в каких случаях это удобно и почему это лучше кодов возврата. Писать очередное объяснение лень, все уже давно написано. Судя по всему, дело в том, что у некоторых людей отсутствует часть мозга, отвечающая за исключения.
                                              0
                                              Еще один аспект не учли — отладка.
                                              Если нужно в отладке оказаться на месте выполнения исключения по ошибке, а в проекте до этого в циклах 100500 раз вызываются исключения для бизнес-логики, то отладка станет мучением.
                                                0
                                                Если я правильно понял вопрос.

                                                Если вы чем-то отделяете 100500-ое исключение от остальных 100499 вы должны об этом в коде явно сказать (сделать ответвление в иерархии наследования исключений). Ни кто же не утверждает что все исключения class-а Exception. Иначе это не чем не будет отличаться от возврата -1.

                                                Даже если этого не делать, у современных Debuger-ов достаточно развиты breakpoint-ы. Если по каким-то причинам их применять тяжело, можно поставить if с условием остановки с пустым телом — breakpoint поставить в нем.

                                                Другими словами это не проблема Exception-ов как таковых.
                                                0
                                                В последнем примере должно быть отрицание:
                                                static class SrcClassHelper
                                                {
                                                  public static void Exec(this SrcClass src)
                                                  {
                                                    if (!src.TryExec()) // Здесь было без !
                                                      throw new MyException();
                                                  }
                                                }
                                                
                                                  0
                                                  Спасибо
                                                  0
                                                  Например, в Java накладным расходом на throw является сохранение в объекте Exception всего stack trace, что являет довольно дорогой операцией. Поэтому такими средствами нужно пользоваться либо в случае некритичности по времени, либо при завершении вселго цикла обработки после обработки исключения. Если же ловить исключение на каждой итерации — просад может быть о-о-очень значительным.
                                                  Так что всему свое место, IMHO.
                                                    0
                                                    Я с вами абсолютно согласен.

                                                    Перехватывать Exception-ы надо только там, где ты точно знаешь как их обработать. Если же мы каждую функцию будем обрамлять в try catch, то это будем ни чем не лучше GetLastError, возврата -1, или макроса ASSERT в который, дядьки с большими головами, советовали обрамлять каждый вызов в C++ коде.
                                                    0
                                                    есть 2 вида реализации работы с исключениями:
                                                    — zero cost, по предгенеренным таблицам, большинство нынешних компиляторов по умолчанию использует этот вариант
                                                    — динамический
                                                    все performance issue исследованы и описаны в «Technical Report on C++ Performance»
                                                    public.research.att.com/~bs/performanceTR.pdf
                                                    можно прочитать и побороть свою throwФобию
                                                      0
                                                      Еще не забываем, что выкидывать исключение надо в действительно исключительной ситуации для обработки ошибок, а не просто ради быстрого выхода из кучи вложенностей
                                                        0
                                                        0
                                                        Мы обычно говорим «кидать», а не поднимать исключения.
                                                          0
                                                          Я как-то об этом не задумывался. Но однозначно существует оба термина. Скорее всего это переводы raise и throw, используемые в разных языках программирования.

                                                        Only users with full accounts can post comments. Log in, please.