Otwieranie pliku z ogólną obsługą błędów

W większości przypadków, gdy potrzebowałem otwierać dowolny plik stosowałem taką, lub podobną konstrukcję:

var
  fInput: File of Byte;
  wCount: Word;
begin
  AssignFile(fInput, 'C:\File.dat');

  try
    Reset(fInput);
    BlockRead(fInput, wCount, SizeOf(wCount));
  finally
    CloseFile(fInput);
  end;

  ReadLn;
end.

Co oczywiście wyklucza obsługę jakichkolwiek błędów podczas odczytu;

Załóżmy, że potrzebuję otworzyć plik, przy czym sprawdzić, czy faktycznie został otwarty, po czym jeśli operacja powiodła się rozpocząć wczytywanie danych; Jeżeli podczas odczytu danych wystąpi błąd to też go wychwycić; Po wszystkim plik zamknąć i gotowe; Błąd podczas odczytu może się zdarzyć jeśli plik będzie uszkodzony, np. zbyt krótki lub wczytywane dane będą nieprawidłowe, np. odczytuję datę, ale pobrany ciąg danych będzie uszkodzony czy przekłamany, czyli wartość dla daty będzie nieprawidłowa;

Na myśl przychodzi taka konstrukcja:

var
  fInput: File of Byte;
  wCount: Word;
begin
  AssignFile(fInput, 'C:\File.dat');

  try
    try
      Reset(fInput);

      try
        BlockRead(fInput, wCount, SizeOf(wCount));
      except
        on Exception do
          WriteLn('Read Exception');
      end;
    finally
      CloseFile(fInput);
    end;
  except
    on Exception do
      Write('Reset Exception.');
  end;

  ReadLn;
end.

i wszystko byłoby w porządku (bo jeśli plik nie istnieje bądź jest blokowany przez inny proces wyjątek zostanie poprawnie przechwycony), jednak żeby następnie przechwycić błąd podczas odczytu danych trzeba było dodać kolejny blok try .. except pod Reset, dzięki czemu tworzy się drabinka, choć taka konstrukcja nawet by mnie satysfakcjonowała, bo spełnia założenia;

Można także wykorzystać obsługę błdów I/O i odpowiednio sprawdzić IOResult:

var
  fInput: File of Byte;
  wCount: Word;
begin
  AssignFile(fInput, 'C:\File.dat');
  {$I-}
  Reset(fInput);
  {$I+}

  if IOResult = 0 then
    try
      try
        BlockRead(fInput, wCount, SizeOf(wCount));
      except
        on Exception do
          WriteLn('Read Exception');
      end;
    finally
      CloseFile(fInput);
    end
  else
    WriteLn('Reset Exception');

  ReadLn;
end.

i też poprawnie zostaje obsłużony błąd otwarcia, a jeśli plik zostanie otwarty poprawnie ale odczyt danych się nie powiedzie - plik zostanie zamknięty a błąd wychwycony i wyświetlony komunikat Read Exception; Taka kontrukcja też spełnia założenia, więc także można by ją wykorzystywać;

Sprawdzam różne konstrukcje i zamykanie pliku w tej sytuacji musi być wykonane jedynie wtedy, gdy IOResult = 0, bo inaczej dostaję nieznany wyjątek programowy; To nie jest dziwne, bo zamkniętego pliku nie można zamknąć;

Moje pytanie brzmi: w jaki sposób poprawnie obsługiwać błędy związane z dostępem do pliku oraz odczytywaniem danych?

Nie potrzebuję rozróżniać nie wiadomo ile błędów, jedynie błąd otwarcia pliku i błąd odczytu danych z pliku; Z racji tej, że na razie nie mam jakiegoś super skutecznego sposobu chciałbym się dowiedzieć w jaki sposób Wy implementujecie obsługę błędów związanych z wczytywaniem danych z pliku; Proszę o przedstawienie Waszych metod, z których korzystacie na co dzień;

Moje pytanie brzmi: w jaki sposób poprawnie obsługiwać błędy związane z dostępem do pliku oraz odczytywaniem danych?

Wszystkie sposoby które przedstawiłeś są poprawne. Osobiście najczęściej używam wysłużonego {$I-} żeby uniknąć wyjątku albo zostawiam {$I+} i po prostu pozwalam się w takim wypadku programowi wyłożyć na głównym systemie obsługi błędów (jeżeli plik musi dać się otworzyć żeby program poprawnie działał).

Proszę o przedstawienie Waszych metod, z których korzystacie na co dzień;

procedure TMyPe.Read(s: ansistring);
var
  f:file of boolean;
  i,j,n:integer;
  oldfmode:byte;
const
  MZMagic:word=23117;
  PEMagic:dword=17744;
begin
  oldfmode:=filemode;
  filemode:=0;
  assign(f,s);
  {$I-}reset(f);
  if IOResult<>0 then raise exception.Create('Cannot read file');
  BlockRead(f,doshead,sizeof(doshead),i);
  if i<>sizeof(doshead) then raise exception.Create('Cannot read header!');
  if MZMagic<>doshead.e_magic then raise exception.Create('This file isn''t magic!');
  n:=filepos(f);
  setlength(subdata,doshead.e_lfanew-n);
  BlockRead(f,subdata[0],length(subdata),i);
  //seek(f,doshead.e_lfanew);
  if filepos(f)<>doshead.e_lfanew then raise exception.Create('Subdata read fail');
  BlockRead(f,nthead,sizeof(nthead),i);
  if i<>sizeof(nthead) then raise exception.Create('Cannot read nt header');
  if nthead.Signature<>PEMagic then raise exception.Create('This isn''t valid file for me.');

Jeżeli nie chciałbym aby program używał wyjątków to zrobił bym sobie result z booleanem albo intem i używał exit(-1); i podobnych. Rozwiązanie może i nieidealne ale preferuję programowanie liniowe nad wiele rozgałęzień i długich bloków if. Jeżeli się zastanawiasz czemu np. tutaj nie używam w ogóle finally aby zwolnić pliki etc. to wynika to z tego że błędy przy odczycie plików zazwyczaj traktuję jako non-recoverable error a ta biblioteka jest używana głównie w aplikacjach konsolowych gdzie wychodzenie z exceptionem nie jest niczym wyjątkowym więc nigdy nawet nie przechwytuję tych wyjątków, najwyżej dodam piękny czerwony komunikat.
Generalnie to w moim kodzie rzadko kiedy można się doszukać bloków finally albo except ponieważ wyjątki traktuję jako poważne problemy które raczej nie powinny występować w przypadku poprawnej operacji programu.

Wg mnie, poprawnie obsługujesz.
Możesz też całość dać w {$I-} {$I+} (lub tylko BlockRead()/BlockWrite) oraz badać IOResult po BlockRead()/BlockWrite;

Albo zostaw w spokoju mechanizm pascala z epoki kamienia łupanego i przejdź na porządny TFileStream obsługa błędów staje się jednolita.

-321oho napisał(a)

Wszystkie sposoby które przedstawiłeś są poprawne.

Poprawne tak, jednak pierwsze nie posiada obsługi błędów, stąd wszystkimi zajmie się system, a to w ogóle nie wchodzi w grę; Chcę obsługiwać wszystkie błędy jakie mogą powstać w programie i sygnalizować je własnym oknem dialogowym (z odpowiednią informacją);

-321oho napisał(a)

Osobiście najczęściej używam wysłużonego {$I-} żeby uniknąć wyjątku albo zostawiam {$I+} i po prostu pozwalam się w takim wypadku programowi wyłożyć na głównym systemie obsługi błędów (jeżeli plik musi dać się otworzyć żeby program poprawnie działał).

Wymienione dyrektywy to dobra sprawa, bo podobnie do wyjątków pozwalają na rozróżnienie typu błędu, ale że jest ich mnóstwo (sygerując się np. tą listą) to wolałbym traktować je ogólnie; Bo użytkownikowi nie są potrzebne takie informacje, po co mu wiedzieć czy uchwyt jest właściwy czy nie, czy suma kontrolna się zgadza itd.; Najważniejszą grupę błędów mam wyznaczoną:

1. plik nie istnieje,
2. brak dostępu do pliku (plik jest blokowany przez inny proces),
3. nieprawidłowa budowa pliku,
4. nieprawidłowy nagłówek,
5. nieoczekiwany koniec pliku (czyli pętla wczytująca odpowiednie bloki danych zbyt wcześnie natrafia na koniec pliku)
   i to w sumie tyle - uznałem, że tylko takie informacje są potrzebne użytkownikowi do ocenienia przyczyny błędu; Niestety (a może nawet "stety") użytkownicy mogą być totalnymi matołami, więc trzeba było wybrać te najważniejsze, które nawet totalny laik potrafiłby zrozumieć i odpowiednio zareagować;

-321oho napisał(a)

Jeżeli nie chciałbym aby program używał wyjątków to zrobił bym sobie result z booleanem albo intem i używał exit(-1); i podobnych. Rozwiązanie może i nieidealne ale preferuję programowanie liniowe nad wiele rozgałęzień i długich bloków if.

Ja nie mam nic przeciwko wyjątkom i mogę je stosować, jednak wychodzenie Exit'em z parametrem nie wchodzi w grę, bo ustalenie kodu wykonania funkcji zaimplementowane jest wewnątrz niej; A co długich if'ów to mnie nie przeszkadzają, nie mam z nimi w ogóle problemów; Czasem jednak lepiej jest przerywać działanie procedury przez Exit i liniowo sprawdzać różne rzeczy, ale to wszystko zależy od wykonywanych operacji;

_13th_Dragon napisał(a)

Albo zostaw w spokoju mechanizm pascala z epoki kamienia łupanego i przejdź na porządny TFileStream obsługa błędów staje się jednolita.

Taka konstrukcja mi nie przeszkadza, bo nie najgorzej się z niej korzysta, ale chyba już czas zacząć korzystać ze strumieni; Naszkicowałem sobie kod realizujący wczytanie pliku do strumienia i odczytujący jedną liczbę, jednak aby obsłużyć błędy musiałem podobnie jak wcześniej zapisać trzy bloki:

var
  fsInput: TFileStream;
  wCount: Word;
begin
  try
    fsInput := TFileStream.Create('C:\File.dat', fmOpenRead or fmShareDenyNone);

    try
      try
        fsInput.ReadBuffer(wCount, SizeOf(wCount));
      except
        on Exception do
          WriteLn('Read Exception');
      end;
    finally
      fsInput.Free();
    end;
  except
    on Exception do
      WriteLn('Open Exception');
  end;

  ReadLn;
end.

W takim przypadku gdy plik nie istnieje lub jest pusty wyświelony zostanie komunikat Open Exception, a jeśli błąd spowoduje kopiowanie danych ze strumienia do zmiennych zostanie wyświetlony komunikat Read Exception; Dobrze myślę, czy wypada to zabezpieczyć inaczej?

Poco tak komplikować:

var
  fsInput: TFileStream;
  wCount: Word;
begin
  try
    fsInput := TFileStream.Create('C:\File.dat', fmOpenRead or fmShareDenyNone);
    fsInput.ReadBuffer(wCount, SizeOf(wCount));
    fsInput.Free();
  except
    on E:EFileCreateError do WriteLn('Nie udało się stworzyć pliku');
    //on E: ....
    on E:Exception do WriteLn('Open Exception '+E.ClassName);
  end;
 
  ReadLn;
end.

Pozostałe rodzaje wyjątków popatrz w źródle lub w dokumentacji lub zwyczajnie metodą eksperymentu, pokaże się nazwa kłasy.

  try
    fsInput := TFileStream.Create('C:\File.dat', fmOpenRead or fmShareDenyNone);
 
    try
      try
        fsInput.ReadBuffer(wCount, SizeOf(wCount));
      except
        on Exception do
          WriteLn('Read Exception');
      end;
    finally
      fsInput.Free();
    end;
  except
    on Exception do
      WriteLn('Open Exception');
  end;

A czemu nie tak?

try
    fsInput := TFileStream.Create('C:\File.dat', fmOpenRead or fmShareDenyNone);
  except
    on Exception do
      WriteLn('Open Exception');
  end;
 
    try
      try
        fsInput.ReadBuffer(wCount, SizeOf(wCount));
      except
        on Exception do
          WriteLn('Read Exception');
      end;
    finally
      fsInput.Free();
    end;

Oczywiście nie masz tu jeszcze rozpoznania błędu, również on Exception do writeln('zgaduje blad'); jest złe bo równie dobrze może wystąpić jakiś problem którego nie przewidziałeś a ty go zaszufladkujesz jako 'coś'.

Ja nie mam nic przeciwko wyjątkom i mogę je stosować, jednak wychodzenie Exit'em z parametrem nie wchodzi w grę, bo ustalenie kodu wykonania funkcji zaimplementowane jest wewnątrz niej;

Zawsze możesz zrobić procedurę która będzie wywoływać generyczną procedurę i z dokładnych kodów błędów wyłapywać te które nas interesują i je zwracać w odpowiedni sposób. Będzie to rozwiązanie które pozwoli pisać zarówno dokładne procedury co poszło nie tak (nr. błędu) jak i ogólnie (wiadomość odpowiadająca zakresowi numerów).

nieprawidłowa budowa pliku,
nieprawidłowy nagłówek,
nieoczekiwany koniec pliku (czyli pętla wczytująca odpowiednie bloki danych zbyt wcześnie natrafia na koniec pliku)

Pierwszy błąd jest ogólną definicją kolejnych dwóch.
Błąd drugi może wynikać z błędu trzeciego.
Błąd trzeci może wynikać np. z uszkodzonego nagłówka który mimo wszystko przeszedł.

Jeżeli chcesz mieć debiloodporną konstrukcję to po prostu wszystko wrzuć do ogólnej definicji 'plik uszkodzony' bo to że wydaje ci się że plik nie powinien się jeszcze kończyć może równie dobrze oznaczać uszkodzenie nagłówka. Nie lubię zbyt dokładnych opisów błędu bo często wprowadzają w błąd.

Poza tym, właściwie nie wiem do czego Furious zmierzasz. Szukasz najlepszej metody odczytu pliku debilo-odpornie? Bo na początku pytałeś o procedury które się używa najczęściej: Najczęściej używa się jednego, góra dwóch komunikatów błędów o problemie z plikami, do tego można dorzucić jakiś numer który coś znaczy (ale nikt nie wie co).