настройка компилятора - не показывать ошибки

юзаю try except... запускаю прогу в компиляторе - всеравно выдает ошибку
компилирую и запускаю сам ексешник - ошибок нет,все норм.

Собственно как отключить эту штуку в компиляторе что бы спокойно можно было из компилятора запускать??
подскажите плиз

Сообщение отредактировано: 8ka - 06.01.11, 19:57

Tools/Options/Debugger/Stop on exceptions.

Цитата 8ka @ 06.01.11, 19:56

Собственно как отключить эту штуку в компиляторе что бы спокойно можно было из компилятора запускать??
подскажите плиз

Не надо это делать!
Тем самым вы сами себе "серпом по фабержам"!
Спокойно "запускать" под встроенном отладчиком (а не "из компилятора", как вы сказали) вам ничего не мешает. Он (отладчик) вам только всегда напоминает об ошибках. И только если вы уверены на 100%, что вы "грамотно" обработали все ошибки, вы можете выключить опцию "Stop on exceptions".
Хотя я не понимаю для чего это нужно!

Цитата northener @ 07.01.11, 00:58

Хотя я не понимаю для чего это нужно!

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

Цитата Alexander N @ 07.01.11, 06:37

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

Если "таких файлов много", то это уже не исключительная ситуация, а вполне штатная, поэтому логичнее было бы просто (локально) отключить генерацию исключений при открытии файлов по {$I-} и проверять успешность по IOResult

Цитата leo @ 07.01.11, 09:40

Если "таких файлов много", то это уже не исключительная ситуация, а вполне штатная, поэтому логичнее было бы просто (локально) отключить генерацию исключений при открытии файлов по {$I-} и проверять успешность по IOResult

Как? Я же через TFileStream работал?

Сообщение отредактировано: Alexander N - 07.01.11, 10:28

Цитата Alexander N @ 07.01.11, 10:24

Как? Я же через TFileStream работал?

Еще лучше - значит нужно было работать через THandleStream + FileOpen\FileClose без всяких IOResult
По любому, как ни крути, а исключение должно быть не правилом, а исключением из правил

Цитата leo @ 07.01.11, 10:50

Еще лучше - значит нужно было работать через THandleStream + FileOpen\FileClose без всяких IOResult

А как позицию хранить? Блоками читать?

Цитата Alexander N @ 07.01.11, 10:53

А как позицию хранить? Блоками читать?

О чем это ты ? TFileStream это совершенно куций фантик для THandleStream, и делает он всего две элементарные вещи:
1) в конструкторе вызывает inherited Create(FileOpen(FileName, Mode)) + проверяет хэндл файла и генерит исключение при FHandle < 0
2) в деструкторе закрывает файл по if FHandle >= 0 then FileClose(FHandle);
Спрашивается, что изменится, если открытие и закрытие файла вынести наружу и юзать THandleStream в "чистом виде" ?

Добавлено 07.01.11, 11:43

var
  h:integer;
  strm:THandleStream;
begin
  ...
  h:=FileOpen(FName,Mode);
  if h >= 0 then
  begin
    strm:=THandleStream.Create(h);
    try
      ...
    finally
      strm.Free;
      FileClose(h);  
    end;
  end
  else
    ... //ошибка открытия файла GetLastError
end;

Сообщение отредактировано: leo - 07.01.11, 11:44

А у меня массив из TFileStream - как его заменить?

Добавлено 07.01.11, 11:57
Переменной длины

Цитата Alexander N @ 07.01.11, 11:57

А у меня массив из TFileStream - как его заменить?

Час от часу не легче
Ну определи тогда свой класс, который будет закрывать файл в деструкторе

type
   TMyFileStream = class(THandleStream)
     destructor Destroy;override;
   end;
destructor TMyFileStream.Destroy;
begin
   if Handle >= 0 then FileClose(Handle);
   inherited;
end;
 
var
   files:array of TMyFileStream;
   h:integer;
begin
   ...
   h:=FileOpen(FName,Mode);
   if h >= 0 then
   begin
     SetLength(files,Length(files)+1);
     files[Length(files)-1]:=TMyFileStream.Create(h);
     ...
   end
   else
     ... //GetLastError
end;

Цитата leo @ 07.01.11, 12:44

Ну определи тогда свой класс, который будет закрывать файл в деструкторе

Ну а зачем, если уже есть TFileStream и его хватает с лихвой?

Цитата Alexander N @ 07.01.11, 13:04

Ну а зачем, если уже есть TFileStream и его хватает с лихвой?

Ага с очень большой лихвой, упомянутой тобой в #4
Реализация TFileStream предполагает, что ошибка открытия файла, это маловероятная = исключительная ситуация, поэтому "безобидно"\"безболезненную" проверку на Handle < 0 превращает в исключительную raise EFOpenError, "ставя на уши" не только саму прогу, но и всю систему в целом - не зря же отладчик "вопит" при каждом исключении

Сообщение отредактировано: leo - 07.01.11, 15:39

Цитата leo @ 07.01.11, 15:38

но и всю систему в целом

Каким образом?

Установка флага Tools/Options/Debugger/Stop on Delphi exceptions в "on" нужна в очень редких случаях (таких даже не припомню).

Используется только для отладки.

Обработка исключений - необходимая и нормальная вещь внутри программы.
Получать же при отладке одно и то же исключение 2 раза - вовсе бессмысленно.

Ко всему прочему, есть компоненты, которые сами обрабатывают исключения (и и гасят их как нужно).

Сообщение отредактировано: Демо - 07.01.11, 17:05

Цитата Демо @ 07.01.11, 17:03

Получать же при отладке одно и то же исключение 2 раза - вовсе бессмысленно.

Это как - два раза одно исключение?

Цитата Alexander N @ 07.01.11, 16:59

Каким образом?

Таким, что в винде единый супернавороченный механизм обработки исключений, как хардварных (типа деления на 0 или AV), так и любых пользовательских, генерируемых через RaiseException. Тут тебе и повышение приоритета обработки исключения, и сохранение\восстановление нихилых структур данных типа контекста потока и "уйма" процессороного времени - порядка нескольких тысяч тактов при отсутствии отладчика и несколько сотен тысяч тактов при наличии отладчика (даже если он не реагирует на исключение, а просто уведомляется системой). И все это вместо того, чтобы просто "втихую" проверить if Handle < 0 then ... за пару тактов процессора ?!

Цитата Alexander N @ 07.01.11, 17:09

Это как - два раза одно исключение?

Сначала Delphi перехватывает исключение и показывает сообщение с ошибкой пользователю, затем вновь поднимает это же исключение в выполняющейся программе.
Т.е. этап обработки исключения самим Delphi - совершенно лишний.

Цитата Демо @ 07.01.11, 18:11

Сначала Delphi перехватывает исключение и показывает сообщение с ошибкой пользователю, затем вновь поднимает это же исключение в выполняющейся программе.
Т.е. этап обработки исключения самим Delphi - совершенно лишний

Это неверная интерпретация, т.к. отладчик никакие исключения (кроме своих брикпойнтов) не обрабатывает и ничего вновь не "поднимает", а просто выводит сообщение\предупреждение о возникшем исключении и дает возможность юзеру продолжить обработку либо в пошаговом режиме с заходом в except\finally, или просто продолжить\проскочить все по F9

Сообщение отредактировано: leo - 07.01.11, 18:21

Согласен, неверно выразился.

В догонку: все же отключать останов на всех исключениях, это "не есть гуд". Но если есть компоненты или просто часть кода, которая "грешит" тем, что часто\непрерывно генерит эксепшены определенного типа, то можно добавить этот тип эксепшена в список Exception Types to Ignore и соотв-но игнорить не все исключения, а лишь определенные. В частности в примере Alexander N можно было бы добавить в список EFOpenError, чтобы не надоедали ошибки открытия файлов

leo, по поводу класса TFileStream и THandleStream Ваша взяла

Цитата leo @ 07.01.11, 17:18

И все это вместо того, чтобы просто "втихую" проверить if Handle < 0 then ... за пару тактов процессора ?!

Ну скажем не просто "не проверить". А дать возможность написать только код для нормального случая. Не засоряя его всеми этими проверками. А что будет, если файл не найден? А что будет, если он пустой? (я, надеюсь, ReadBeffer используется?) А что будет, если формат данных неверен?