Mint minden újabb OO nyelvben, a Satherben is van kivételkezelés. Két szempontot fogunk vizsgálni: hol és miért váltódnak ki kivételek, valamint hol és hogyan kezelhetjük le azokat.
Minden kiváltott kivétel tovább terjed, egy felsőbb szintre adódik át, hacsak egy ‘protect’ blokkban el nem kapjuk. Ilyen állításokkal foghatjuk körül a védendő kódot, ezzel kezelhetjük le az onnan kijövő kivételeket. A ‘protect’ kifejezés tulajdonképpen egy ‘typecase’-t rejt magában, az eldobott objektumot a típusa szerint kaphatjuk el (mindig az első olyan ágat választja ki, amelynek megfelel a dobott objektum). Célszerű, de nem kötelező kivétel osztályt definiálni. Magát azt az objektumot, ami kivételként lépett fel az adott ágon belül az exception kifejezéssel tudjuk elérni. A megfelelő ágakon a typecase feltételével azonos lesz a típusa, az else ágon pedig $OB lesz (minden osztály őse). Ha egy kivételt egy protect nem kezel le, akkor az egy magasabb szintre tovább adódik.
Érdekesség, hogy ilyen védőburok az eljárásoktól függetlenül, utólag is definiálható:
protect
foo;
when $STR then
#ERR + "An error in foo!:" + exception.str; -- itt $STR típusú
when INT then
#ERR + "INT error=" + exception; -- itt INT típusú
else
-- itt pedig $OB típusú lesz az exception
end;
Ebben a példában a foo metódushívást akarjuk “védeni”, ezért foglaltuk protect blokkba. Ha a foo kivált egy exception-t, vagy nem kezel le, és tovább adódik, akkor itt elkaphatjuk.
Ajánlás: kivételek kezelése igencsak lassú, ezért nem javasolt függvényhívás helyett használni. Nem is arra való. Elnevezésének megfelelően kivételes helyzetek kezelésére használjuk csak.
Kivételek helyett használjuk következetesen minden eljárásnál hibakódokat (IEEE kivételek), persze ez sok hibalehetőséget felvet, de előnyökkel is jár használata (pl utasítás szintű védelem, és nem blokk).
Mi is tudunk kivételt kiváltani a ‘raise’ kulcsszóval, ami tetszőleges objektumot, mint kivételt kivált.