Cтратегии обработки ошибок
От: emag  
Дата: 17.03.04 14:18
Оценка:
Привет.

Подскажите, существуют ли какие-то общие стратегии обработки ошибок, применяемые при разработке крупных программных продуктов? Меня интересуют как методологические разработки данного вопроса, так и описание практического опыта. Скажем такие частные вопросы:

1. Использовать механизм исключений или анализ возвращаемого значения для обнаружения ошибок.

2. Централизованная обработка ошибок или обработка ошибок на месте. Под централизованной обработкой я имею в виду систему, где каждая операция проходит через некоторый, скажем, контроллер. Единственным назначением данного контроллера является анализ результата операции на предмет наличия ошибки (проверка возвращаемого значения, перехват исключения и т.п.) и публикация этого результата (лог, сообщение пользователю). Под децентрализованой системой я имею в виду систему, где ошибки обрабатываются и публикуются прямо на месте ее возникновения.

У каждого из этих вариантов мне видятся как свои достоинства так и свои недостатки. Полное отсутствие какой-либо систематизации также не рассматривается как большое преимущество. Хотелось бы выслушать ваши мнения по данному вопросу.
Re: Cтратегии обработки ошибок
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 17.03.04 14:27
Оценка: 3 (1) +2
E>1. Использовать механизм исключений или анализ возвращаемого значения для обнаружения ошибок.

Механизм исключений.


E>2. Централизованная обработка ошибок или обработка ошибок на месте. Под централизованной обработкой я имею в виду систему, где каждая операция проходит через некоторый, скажем, контроллер. Единственным назначением данного контроллера является анализ результата операции на предмет наличия ошибки (проверка возвращаемого значения, перехват исключения и т.п.) и публикация этого результата (лог, сообщение пользователю). Под децентрализованой системой я имею в виду систему, где ошибки обрабатываются и публикуются прямо на месте ее возникновения.


Центральная — причем, она делается в первую очередь, на случай в том числе и непредвиденных ошибок).
Далее добавляются локальные обработчики для тех случаев, когда по месту мы можем точнее понять/устранить причину ошибки.
Re[2]: Cтратегии обработки ошибок
От: Краснокутский Василий Россия  
Дата: 17.03.04 14:53
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>Центральная — причем, она делается в первую очередь, на случай в том числе и непредвиденных ошибок).

DG>Далее добавляются локальные обработчики для тех случаев, когда по месту мы можем точнее понять/устранить причину ошибки.

Очень интересный вопрос — а нельзя ли привести несколько примеров ? Например для работы с GUI, клиент-сервера ну и т.п.
Re[3]: Cтратегии обработки ошибок
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 17.03.04 15:13
Оценка:
DG>>Центральная — причем, она делается в первую очередь, на случай в том числе и непредвиденных ошибок).
DG>>Далее добавляются локальные обработчики для тех случаев, когда по месту мы можем точнее понять/устранить причину ошибки.

КВ>Очень интересный вопрос — а нельзя ли привести несколько примеров ? Например для работы с GUI, клиент-сервера ну и т.п.


while(GetMessage())
{
   try
   {
     TranslateMessage();
   }
   catch(exception exc)
   {
      ОкноОшибок.ВывестиОшибку(exc.Message);
   }
}


Это центральная обработка.
Которая хорошо себя ведет даже для непредвиденных ошибок, например, программа была запущена с CD.
т.е. если пользователь "нажмет" команду "сохранить настройки", а диск защищен от записи, то пользователь получит корректное поведение: выведется сообщение об ошибке.

  void SaveOptions()
  {
    try
    {
      SaveOptionToDefaultFile();
    }
    catch (IOException exc)
    {
      СпроситьПользователяОДругомМестеСохраненияНастроек();
      SaveOptionsToAnotherFile();      
    }

  }

Добавили локальную обработку, т.к. здесь мы точнее знаем, что необходимо делать, если не записался файл настроек.
Re: Cтратегии обработки ошибок
От: Аноним  
Дата: 17.03.04 15:24
Оценка: 11 (2)
Здравствуйте, emag, Вы писали:

E>Привет.


E>Подскажите, существуют ли какие-то общие стратегии обработки ошибок, применяемые при разработке крупных программных продуктов? Меня интересуют как методологические разработки данного вопроса, так и описание практического опыта. Скажем такие частные вопросы:


E>1. Использовать механизм исключений или анализ возвращаемого значения для обнаружения ошибок.


E>2. Централизованная обработка ошибок или обработка ошибок на месте. Под централизованной обработкой я имею в виду систему, где каждая операция проходит через некоторый, скажем, контроллер. Единственным назначением данного контроллера является анализ результата операции на предмет наличия ошибки (проверка возвращаемого значения, перехват исключения и т.п.) и публикация этого результата (лог, сообщение пользователю). Под децентрализованой системой я имею в виду систему, где ошибки обрабатываются и публикуются прямо на месте ее возникновения.


E>У каждого из этих вариантов мне видятся как свои достоинства так и свои недостатки. Полное отсутствие какой-либо систематизации также не рассматривается как большое преимущество. Хотелось бы выслушать ваши мнения по данному вопросу.


Error Handling for Business Information Systems
Re: Cтратегии обработки ошибок
От: uriy999 Россия http://yurnik.narod.ru
Дата: 17.03.04 15:25
Оценка: 10 (2)
Здравствуйте, emag, Вы писали:

E>Привет.


E>Подскажите, существуют ли какие-то общие стратегии обработки ошибок, применяемые при разработке крупных программных продуктов? Меня интересуют как методологические разработки данного вопроса, так и описание практического опыта. Скажем такие частные вопросы:


Полезный паттерн/стратегия генерации и обработки исключений приводиться в книге Крега Лармана "Применение UML и паттернов проектирвоания. Введени в OOD/A и UP".
Там есть примерно такие идеи:
— "Подсистеме не следует выкидывать исключение более низких уровней, дабы не раскрывать своего внутреннего устройства".
— Полезно соединять исключения в цепочки. Затем можно вывести сообщения о причинах ошибки от высокоуровневых — до низкоуровневых. Очень полезно.
— "Name the problem not the thrower" — касаемо именования класса исключений, давайте ему название проблемы, а не источника этой проблемы. Тогда обработка будет понятней и система гибкой, расшираемой.

Приводится в пример — уровневая архитектура, ошибки одного уровня обрабатываются непоследственным вышележащим уровнем и никогда не передаются дальше.

У меня есть еще одна ссылка (я сам использую такую подсистему, довольно успешно):
http://www.objectarchitects.de/arcus/cookbook/exhandling/
Усё уже украдено — до нас...
Re: Cтратегии обработки ошибок
От: FreshMeat Россия http://www.rsdn.org
Дата: 17.03.04 17:05
Оценка:
Здравствуйте, emag, Вы писали:

E>1. Использовать механизм исключений или анализ возвращаемого значения для обнаружения ошибок.

http://www.rsdn.ru/Forum/Message.aspx?mid=479157&only=1
Автор: Vladimir_K
Дата: 16.12.03
Хорошо там, где мы есть! :)
Re: Cтратегии обработки ошибок
От: krpav  
Дата: 18.03.04 01:17
Оценка: 3 (1)
Здравствуйте, emag, Вы писали:

E>Привет.


E>Подскажите, существуют ли какие-то общие стратегии обработки ошибок, применяемые при разработке крупных программных продуктов? Меня интересуют как методологические разработки данного вопроса, так и описание практического опыта. Скажем такие частные вопросы:


E>1. Использовать механизм исключений или анализ возвращаемого значения для обнаружения ошибок.


E>2. Централизованная обработка ошибок или обработка ошибок на месте. Под централизованной обработкой я имею в виду систему, где каждая операция проходит через некоторый, скажем, контроллер. Единственным назначением данного контроллера является анализ результата операции на предмет наличия ошибки (проверка возвращаемого значения, перехват исключения и т.п.) и публикация этого результата (лог, сообщение пользователю). Под децентрализованой системой я имею в виду систему, где ошибки обрабатываются и публикуются прямо на месте ее возникновения.


E>У каждого из этих вариантов мне видятся как свои достоинства так и свои недостатки. Полное отсутствие какой-либо систематизации также не рассматривается как большое преимущество. Хотелось бы выслушать ваши мнения по данному вопросу.



Exception Management Architecture Guide
This document discusses design and implementation guidelines for exception management systems that use .NET technologies. It focuses on the process of handling exceptions within .NET applications in a highly maintainable and supportable manner.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/exceptdotnet.asp

Все разложено по полочкам, должен прочесть каждый разрабочик.
Re[2]: Cтратегии обработки ошибок
От: Maxis Россия http://www.fotki.com/maxis/
Дата: 24.03.04 16:13
Оценка:
Здравствуйте, DarkGray, Вы писали:

E>>1. Использовать механизм исключений или анализ возвращаемого значения для обнаружения ошибок.


DG>Механизм исключений.



E>>2. Централизованная обработка ошибок или обработка ошибок на месте. Под централизованной обработкой я имею в виду систему, где каждая операция проходит через некоторый, скажем, контроллер. Единственным назначением данного контроллера является анализ результата операции на предмет наличия ошибки (проверка возвращаемого значения, перехват исключения и т.п.) и публикация этого результата (лог, сообщение пользователю). Под децентрализованой системой я имею в виду систему, где ошибки обрабатываются и публикуются прямо на месте ее возникновения.


DG>Центральная — причем, она делается в первую очередь, на случай в том числе и непредвиденных ошибок).

DG>Далее добавляются локальные обработчики для тех случаев, когда по месту мы можем точнее понять/устранить причину ошибки.

А вот на каком уровне делать эту "центральную" обработку?
Re[3]: Cтратегии обработки ошибок
От: Коваленко Дмитрий Россия http://www.ibprovider.com
Дата: 28.03.04 11:26
Оценка:
Здравствуйте, Краснокутский Василий, Вы писали:

КВ>Здравствуйте, DarkGray, Вы писали:


DG>>Центральная — причем, она делается в первую очередь, на случай в том числе и непредвиденных ошибок).

DG>>Далее добавляются локальные обработчики для тех случаев, когда по месту мы можем точнее понять/устранить причину ошибки.

КВ>Очень интересный вопрос — а нельзя ли привести несколько примеров ? Например для работы с GUI, клиент-сервера ну и т.п.


Вот код на C++, который используется в моем OLEDB-провайдере для InterBase для централизованной обработки всех ошибок.

//Создает OLEDB ошибку или ошибку автоматизации
HRESULT IBP_OLEDBErrorExceptionHandler(REFCLSID              ProviderCLSID,
                                       REFIID                exc_riid,
                                       const std::exception* exc)
{
 assert(ProviderCLSID==CLSID_IBProvider);
 
 if(exc==NULL)
  return IBP_OLEDBErrorHandler(ProviderCLSID,exc_riid,E_UNEXPECTED,NULL);

 if(const t_ibp_error_ex* x=dynamic_cast<const t_ibp_error_ex*>(exc))
  return x->create_error_info(exc_riid);

 if(const t_win32_error* x=dynamic_cast<const t_win32_error*>(exc))
  return IBP_OLEDBErrorHandler(ProviderCLSID,exc_riid,HRESULT_FROM_WIN32(x->code()),NULL);

 if(const t_base_ole_error* x=dynamic_cast<const t_base_ole_error*>(exc))
  return IBP_OLEDBErrorHandler(ProviderCLSID,exc_riid,x->code(),x->text().c_str());

 if(dynamic_cast<const bad_alloc*>(exc)!=NULL)
  return IBP_OLEDBErrorHandler(ProviderCLSID,exc_riid,E_OUTOFMEMORY,NULL);

 return IBP_OLEDBErrorHandler(ProviderCLSID,exc_riid,E_FAIL,exc->what());
}//IBP_OLEDBErrorExceptionHandler


Вот ветка
Автор: Коваленко Дмитрий
Дата: 19.02.03
, в которой я доходил до этой реализации
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.