🚀 go-pugleaf

Kszysiec wrote:

> Witam !

Ja takze !

> Własnie sobie troche poczytałem o Eiffel'u i zastanowily mnie pewne
> rzeczy :
> Mianowicie jak mogłbym przekazywac informacje o zaistnialym wyjatku w
> ramach obslugi wyjatkow tzn nie z pomoca dodatkowych pol obiektu ani
> tym podobnych "statusow" ( gdybym potrzebowal takiego np. zachowania -
> dana operacja jesli sie wykonala, wykonala sie dobrze jesli cos bylo
> nie tak, mamy wyjatek ) O ile zrozumialem dostajemy informacje o tym
> ze wyjatek nastapil nie wiemy natomiast jakiego typu ( scislej nie
> chodzi mi o to by byl takiego czy innego typu ale by mogl niesc jakas
> informacje oprocz swojej egzystencji).I dalej - jak moglbym wyrzucic
> wyjatek "na sile"  tzn. blad nie wynika z kontraktu ani tez nie jest
> spowodowany przez system ( a moze nie ma innych  bledow ? - w takim
> razie jak "przemianowac" w trakcie propagacji taki wyjatek ?).

No wiec odpowiadajac (mniej lub bardziej) po kolei:

To co mozna znalezc w inecie to sa informacje o podstawowej obsludze
wyjatkow. Przedstawione mechanizmy sa wbudowane do jezyka (klauzule
rescue i retry). Jesli dac wiare B. Meyerowi to w wielu przypadkach jest
to wystarczajace. Dla tych niewystarczajacych przypadkow przewidziano
klase biblioteczna EXCEPTIONS.
Dostarcza ona wielu potrzebnych (i Ciebie wlasnie interesujacych)
mechanizmow. Najwazniejszym sa tzw. queries, czyli zapytania dotyczace
ostatniego wyjatku. Mozemy zapytac m.in. o kod ostatniego wyjatku lub
kod oryginalnego - pierwszego w lancuchu wywolan - wyjatku (kody sa 
liczbami naturalnymi i daja sie odcyfrowac jako np. zlamanie 'class 
invariant', brak pamieci, czy co tam innego).
Mozemy takze pytac czy bylo to zlamanie asercji 
(is_assertion_violation), czy moze blad systemowy (is_system_exception), 
albo ...
Mozna poprosic o opis wyjatku (metoda meaning(except_code : INTEGER)), a
nawet o nazwe procedury w ktorej wyjatek wystapil.
Wreszcie mozna zglaszac wlasne wyjatki (zwane tutaj 'developer
exceptions').
Sluzy do tego metoda trigger(code : INTEGER; message : STRING).
Aby badac (lapac) takie wyjatki mozemy posluzyc sie metodami:

        developer_exception_code : INTEGER
                -- kod ostatniego wyjatku uzytkownika

        developer_exception_name : STRING
                -- nazwa zwiazana z ostatnim wyjatkiem uzytkownika

        is_developer_exception : BOOLEAN
                -- czy ostatni wyjatek byl wynikiem wyjatku uzytkownika

        is_developer_exception_of_name (name : STRING) : BOOLEAN
                -- czy ostatni wyjatek byl wynikiem wyjatku uzytkownika
                -- o nazwie 'name'

Mozna wreszcie z wyjatkiem uzytkownika zwiazac 'kontekst' (czyli 'any
object structure that may be useful to the software element handling
the exception').

> Nie wczytywalem sie w wiele zrodel ( doc-e na www.eiffel.com i "Eiffel
> : An Advanced Introduction") ale zdaje sie ze z ich pomoca jednak
> albo nie zlapalem idei obslugi wyjatkow w tym jezyku  albo czegos nie
> doczytalem choc raczej to pierwsze :).Czy moglby mi ktos albo wyjasnic

Ha !
To co mozna znalezc w inecie jest tylko polizaniem lizaka. Innymi slowy:
"Skoro juz zobaczyles jaki ten Eiffel piekny to moze kupisz rownie
piekna ksiazke (tu wpisac tytul) Bertranda Meyera ...".

> jak zrealizowac wspomniane operacje w tym jezyku albo krotko wyjasnic
> dlaczego Eiffel jest wlasnie taki a nie inny ( dlaczego wystarczy
> rescue i retry takie jakie sa).Inna sprawa ze moze mam nieco
> skrzywiony poglad na sama obsluge wyjatkow ( to pewnie przez to C++
> :)))).

Jak juz wspomnialem wyjasnienia mozna znalezc oczywiscie w ksiazkach BM
- ja to znalazlem w "Object-Oriented Software Construction. Second
Edition" (rozdzial 12 pt. "When the contract is broken: exception
handling"). Mozna
sie tam dowiedziec m.in. czemu wyjatki w Eiffelu sa 'cacy' a w innych
jezykach (np. Adzie) nie 'cacy'.

Pozdrowienia,
MiPr