По-прежнему появляется сообщение об ошибке, даже если ApplyUpdates находится внутри try ... кроме

Question

Решение найдено, см. Мой комментарий ниже

D5, odbc для базы данных mysql

Этот код:

  with QryCmdPerf do begin
    Close;
    ParamByName('ACCTID').AsInteger:= AcctId;
    ParamByName('FROMDT').AsString:= MySQLDate(FromDt);
    ParamByName('TODT').AsString:= MySQLDate(ToDt);
    Open;
    first;
    try
      edit;
      FieldByName('PnL').AsFloat:= 97979;
      ApplyUpdates;
    except
      close;
    end;
  end;    // with

(в частности, «ApplyUpdates») вызывает всплывающее окно с текстом «Ошибка обновления», если поле PnL уже имеет значение 97979, очевидно из-за этого кода:

procedure TUpdateSQL.ExecSQL(UpdateKind: TUpdateKind);
begin
  with Query[UpdateKind] do
  begin
    Prepare;
    ExecSQL;
    if RowsAffected <> 1 then DatabaseError(SUpdateFailed);
  end;
end;

в DBTables.pas. В любом случае, я хочу иметь возможность выпускать ApplyUpdates, и мне не нужно беспокоиться о всплывающем окне, если оно не выполняет никаких обновлений. Но если «попробуй ... кроме» не сработает, что будет?

ТИА

Answer 1

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

• Почему я продолжаю получать сообщения об ошибках даже после написания обработчика исключений?

Он описывает несколько способов избежать вмешательства отладчика:

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

Answer 2

Краткий ответ: вы должны установить обработчик событий для OnUpdateError, или никакое количество блоков «try ... Кроме» не будет блокировать всплывающее окно. Длинный ответ - это ошибка в odbc. Репродукция здесь: http://www.codeupload.com/3919 для всех, кто хочет взглянуть на нее. Вы можете пропустить материал MySQL, подойдет любая база данных odbc.

Answer 3

Здесь есть две вещи, которые могут пойти не так.

Опция 1

Во-первых, некоторый «очень плохой код» может вызвать короткое замыкание раскрутки стека вызовов при исключениях.Например, ApplyUpdates или одна из его дочерних подпрограмм может также иметь блок try...except, который напрямую вызывает Application.HandleException.

Чтобы проверить это, если вы ставите точку останова на QryCmdPerf.Close, достигаете ли вы ее?
Если нет, то Application.HandleException (или хуже Application.ShowException) был вызван напрямую.

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

Опция 2

Если вы достигли точки останова, но исключение вызывается снова, тогда решить его будет намного проще.

Метод Close, вероятно, пытается сохранить любые ожидающие изменения, поэтомуэффективно применяя обновления снова.Вместо того, чтобы просто закрывать набор данных, вызовите CancelChanges или эквивалентный.