CYFROWY BARON • PROGRAMOWANIE

Za każdym razem gdy są zapisywane jakieś dane do jednego z plików programu, może wystąpić konkretny błąd, np. plik nie istnieje lub był już wcześniej otwarty. W programie mam wielokrotne zapisy do pliku przez różne funkcje w różnych sytuacjach. Czy można obsłużyć wyjątek, np. typowy I/OException dla całego programu, bez znaczenia z której funkcji czy klasy "powstał" ? Najczęściej w takim wypadku, jeśli błąd nie jest obsłużony dla każdej napisanej funkcji zapisu do pliku, to program się rozpada, a dane użytkownika idą w zapomnienie. Gdybym mógł go wyłapać, wtedy można by dać awaryjny zapis do pliku, czy coś w tym stylu.

Można coś takiego zrobić, czy trzeba każdą szansę wystąpienia obsłużyć indywidualnie ?

Nigdy o czymś podobnym nie słyszałem. Musisz chyba obsługiwać wszystko indywidualnie...

Indywidualnie. Będzie to również zgodne z tym, co podają podręczniki, aby try znajdowało się jak najbliżej miejsca możliwego wystąpienia wyjątku.

Dla mnie blok try catch to ostateczność, staram się raczej przewidywać możliwe wystąpienia niż wyłapywać na ślepo wszystko co się da, dlatego takie globalne łapanie byłoby bardzo przydatne.

Tu się zgadzam. Try jest głównie do sytuacji całkowicie nieprzewidywalnych i raczej niemozliwych do obsługi "lżejszym" kodem. Moim zdaniem, gdzie się tylko da, obsługiwać warunkami itp. Try pozostawić na ostateczność i opatrznośc Napchanie try catch w programie może go zauważalnie spowolnić.
A jakby miało wyglądać globalne łapanie różnych wyjątków? Mam na myśli całkowicie globalne, ponadklasowe, ponad przestrzeniami nazw, coś, co czuwa nad aplikacją. Może jakaś wielowątkowośc "nasłuchująca" i czuwająca nad całością...

Przecież każda aplikacja w VCL-u ma globalne wyłapywanie wyjątków:

Większość lepszych bibliotek GUI ma taką globalną obsługę wyjątków. Oczywiście każdy wątek, jeśli mówimy o aplikacjach wielowątkowych, musi mieć swoją własną obsługę.

Slynx chyba nie to chodzi, nie w takim wymiarze:

Slynx napisał(a):może wystąpić konkretny błąd, np. plik nie istnieje

To, że plik nie istnieje zostanie oczywiście zgłoszone odpowiednim komunikatem błędu w języku angielskim, ale nie da się na to zareagować z poziomu kodu dla konkretnego formularza. Trzeba by zaimplementować obsługę wszystkich takich błędów w bloku, który pokazałeś.

Nie wiem o co dokładnie chodzi Slynx, ale chyba nie o to, gdyż:

Slynx napisał(a):może wystąpić konkretny błąd, np. plik [...] był już wcześniej otwarty

To, że plik był wcześniej otwarty nie jest błędem.

Slynx chyba nie to chodzi, nie w takim wymiarze:

Odnosiłem się do tego, co napisał usermaw. No ale nieważne...

Przecież każda aplikacja w VCL-u ma globalne wyłapywanie wyjątków:

Zrobienie czegoś takiego jak pokazałeś będzie równoznaczne z tym co mówił usermaw

Napchanie try catch w programie może go zauważalnie spowolnić.

A nie o to mi chodzi, żeby jakaś zewnętrzna konstrukcja (try catch) wisiała nad całą aplikacją. Chodzi bardziej o wyłapywanie W RAZIE wystąpienia, a nie ciągłe OCZEKIWANIE na wystąpienie.

Nie wiem o co dokładnie chodzi Slynx, ale chyba nie o to, gdyż:

Slynx napisał(a):
może wystąpić konkretny błąd, np. plik [...] był już wcześniej otwarty


To, że plik był wcześniej otwarty nie jest błędem.

Z punktu widzenia funkcji - owszem, ale z poziomu błędu programisty - wiadomo. Numer bardzo znany z Pascala, gdzie niezamknięcie pliku (Close)powodowało od razu błąd krytyczny i dane "bye bye".

Slynx chyba nie to chodzi, nie w takim wymiarze:

Slynx napisał(a):
może wystąpić konkretny błąd, np. plik nie istnieje


To, że plik nie istnieje zostanie oczywiście zgłoszone odpowiednim komunikatem błędu w języku angielskim, ale nie da się na to zareagować z poziomu kodu dla konkretnego formularza. Trzeba by zaimplementować obsługę wszystkich takich błędów w bloku, który pokazałeś.

O tym właśnie mówiłem. O globalnym wyłapaniu ewentualnego wystąpienia. Problem jest bardzo prosty, ale rozwiązanie może być trochę trudne. Dlaczego tylko trudne ? Bo chyba wiem jak to zrobić. Muszę jeszcze sprawdzić parę rzeczy i możliwe, że będzie można zwyczajnie odpalić dodatkową klasę, działającą w tle, która będzie wyłapywać błędy. Na razie jednak trochę kombinuje, bo takie rozwiązanie może być gorsze i mniej optymalne od konstrukcji try catch. Muszę trochę pogrzebać na msdn, jak znajdę chwilę czasu.

Powracam do tematu, ale w trochę innej formie.
Wszystkie funkcje mają już pewną obsługę, wyrzucają błędy tylko... no właśnie, jeszcze nie wiem gdzie mają je wyrzucać. Stworzyłem specjalną klasę do obsługi tego, wraz z identyfikatorami i przypisanymi tekstowymi błędami, co pozwoli później na ewentualne łatwe przygotowanie innej wersji językowej (polskiej ). Co jest problemem...
Wcześniej każda funkcja zwracała albo String^ z informacjami od funkcji albo ewentualny błąd z klasy błędów (static Error class), ale teraz zauważyłem, że to zły pomysł, bo niektóre funkcje nie zwracają typu String^, a jakieś własne tablice danego typu.
Jak na razie wykombinowałem, że można zmodyfikować klasę Error, żeby zawierała pewne dodatkowe funkcje, np.

Bardzo przydatne byłoby np. informacja z klasy od której błąd pochodzi. To przy okazji obsłużyło by globalny Log programu. Oczywiście miejsce na przechowywanie to jakiś stos lub lista.
Co o tym myślicie ? Ma ktoś jakiś lepszy pomysł ?
C# nie ma tego problemu, throw exception i tyle...
Przy okazji, miałem zapytać jeszcze o coś.


Pytanie: Czy funkcja break_ może przerwać pętle w której została wywołana ? Czyli, czy można tak napisać tą funkcję break_, że gdy zostanie wywołana w pętli funkcji w której została wywołana(czyli while_()) - przerwie ją ?
Jeśli nie zrozumiałe... Czy funkcja break_() może zawierać break; który przerwie pętlę jeśli funkcja została w niej wywołana ?

----
Jeśli chodzi o to pierwsze, to w sumie już nie ważne. Wspomogłem się nullptr. No chyba, że ktoś ma jakiś na prawdę błyskotliwy pomysł ; )

Jeśli chodzi o break_, odpowiedź brzmi: nie, chyba że rzucisz wyjątkiem lub po prostu zwrócisz wartość, która spowoduje przerwanie pętli w konwencjonalny sposób.