Определение "Обращайся выше" - PullRequest
Новая
       4

Определение "Обращайся выше"

0 голосов
/ 05 декабря 2009

В трассировке стека вызов метода в верхней части является последним вызванным методом.

Когда упоминается фраза «обрабатывай его выше», означает ли это в методе вызывающей стороне или вызывать другой метод в блоке catch?

Кроме того, в многоуровневом приложении с API, который я написал, кажется, что лучшая стратегия состоит в том, чтобы всегда регистрировать исключение и обрабатывать его, как только я смогу, и повторно вызывать его, чтобы вызывающий метод в пользовательском интерфейсе мог отображать ошибку , Есть ли другой сценарий использования для исключения исключения?

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

Спасибо

1 Ответ

3 голосов
/ 05 декабря 2009

  1. Чем выше, тем выше в стеке, да.

  2. Если вы собираетесь изменить способ повторной попытки - то есть, стратегия, которую вы знаете, БУДЕТ работать, или набор стратегий, из которых будет работать ОДИН, тогда, возможно, вы можете сделать это в улове; однако коды ошибок из функций или bool, вероятно, лучше; это потому, что мы не на самом деле говорим об исключительном поведении.

  3. Обработка исключений НЕ является циклическим механизмом, нет. Повторная попытка снова и снова является злом внутри исключений.

  4. Часто вы должны регистрировать исключения, но это не является основной целью исключений. Исключениями является их стандартный механизм восстановления после исключительного поведения хорошо документированным (в коде) способом. Они заменили операторы goto и longjmp в C и C ++. Где, если что-то пойдет не так, вы сделаете абсолютный переход к метке где-нибудь в вашем коде.

  5. протоколирование исключения и повторный бросок это хорошо, это общепринятая конвенция

Пример и обсуждение

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

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

  1. Вы можете начать новую регрессию кода из исключения (как вы упоминали выше), повторив попытку (не снова и снова, хотя: P). Но это новый регресс вашего кода, и это неправильно.

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

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

код: 1 

try{...}
catch{alternateStrategy()}

код: 2 

try
{
   IAmALabel:
   checkFileLock(timeoutVal);
}
Catch
{
   timeoutVal = timeoutVal*2;
   goto IamALabel;
}

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

код 3: 

int tries=3;
while(true)
{
   int ret=CheckFileLock(timeoutVal);
   if(ret==0) // 0 = success, anything else represents a distinct error.
      break;
   tries--;

   if(tries==0)
      throw exception();
}
...