Globalna obsługa błędów programu...

[Slynx]

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 ?

[Cyfrowy Baron]

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

[usermaw]

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.

[Slynx]

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.

[usermaw]

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ą...

[polymorphism]

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

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

WINAPI WinMain(...)
{
        try
        {
                ...
                Application->Run(); // pętla komunikatów, to stąd wszystkie wyjątki będą pochodzić.
        }
        catch (Exception &exception)
        {
                Application->ShowException(&exception);
        }
        return 0;
}
 

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ę.

[Cyfrowy Baron]

Slynx chyba nie to chodzi, nie w takim wymiarze:

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ż:

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.

[polymorphism]

Slynx chyba nie to chodzi, nie w takim wymiarze:

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

[Slynx]

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.

[Slynx]

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.

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

Error::AddErrorMessage("Wiadomość", typ);
 

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ś.

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

Void break_()
{
 /// jakiś kod
}
 

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

void while_()
{
    int i = 0;
    while (1)
        {
        i++;
        if (i == 10) break_();
        }
}
 

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ł ; )

[polymorphism]

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.