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


MH>>Господа, кто на практике к чему пришел в подобных случаях?

F>- Либо пойманное исключение никак не меняется и отправляется выше (try/catch выполняет только подчистку или даже отсутсвует вообще если подчищать нечего), это по-умолчанию.

F>- Либо выбрасывается собственное исключение, где исходное содержится в Inner либо даже отсутствует вообще (если считается, что более полезной информации в нем не осталось). Это для случая, когда возможно вызывающему коду как-то более осмысленно описать ситуацию.

это ок. а как бы вы сделали в следующем случае — допустим есть процесс приёма заказа, допустим при его сохранении есть настраиваемые пользователем "триггеры". допустим триггер — содержит некое условие срабатывания и некое описание действия. допустим что или в настраиваемом пользователем условии или действии возможны ошибки времени выполнения. соотвественно есть процедура ApplayCustomsTriggers, внутри обработка каждого триггера. и вот подошли к основному вопросу — внутри ApplayCustomsTriggers надо ловить ошибку обработки каждого триггера и её поднимать выше (тк это по сути и есть основное исключение), но к информации имеющейся в исключении нужно присобачить доп. информацию, а именно — в каком конкретно тригере это случилось.
подобных примеров можно найти много, главная суть — поднимаемое выше исключение необходимости менять нет (ибо они и несёт основную инфу об ошибке и именно с ним и хочется разбираться) но к нему хочется добавить дополнительную тех. инфу...

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


MH>>Господа, кто на практике к чему пришел в подобных случаях?

F>- Либо пойманное исключение никак не меняется и отправляется выше (try/catch выполняет только подчистку или даже отсутсвует вообще если подчищать нечего), это по-умолчанию.

F>- Либо выбрасывается собственное исключение, где исходное содержится в Inner либо даже отсутствует вообще (если считается, что более полезной информации в нем не осталось). Это для случая, когда возможно вызывающему коду как-то более осмысленно описать ситуацию.

это ок. а как бы вы сделали в следующем случае — допустим есть процесс приёма заказа, допустим при его сохранении есть настраиваемые пользователем "триггеры". допустим триггер — содержит некое условие срабатывания и некое описание действия. допустим что или в настраиваемом пользователем условии или действии возможны ошибки времени выполнения. соотвественно есть процедура ApplayCustomsTriggers, внутри обработка каждого триггера. и вот подошли к основному вопросу — внутри ApplayCustomsTriggers надо ловить ошибку обработки каждого триггера и её поднимать выше (тк это по сути и есть основное исключение), но к информации имеющейся в исключении нужно присобачить доп. информацию, а именно — в каком конкретно тригере это случилось.
подобных примеров можно найти много, главная суть — поднимаемое выше исключение необходимости менять нет (ибо оно и несёт основную инфу об ошибке и именно с ним и надо разбираться выше) но к нему хочется добавить дополнительную тех. инфу...