Книга е още в много ранна фаза на написване

9: Обработка на грешки чрез изключения

Както и със C++, идеалния момент да се хване грешка е времето на ком­пи­ла­ция, преди даже да се опитате да пуснете програмата. Обаче не всички грешки мо­гат да бъдат открити по време на компилация. Определена част проблеми мо­гат да се обработват само по време на изпълнение, по някакъв формализъм, къ­дето източникът на грешката трябва да има начин да подаде информация на ко­да, който ще я обработва, за да може обработката да бъде подходяща.

В C и други ранни езици можеше да съществуват няколко такива формализма, а освен това те бяха задавани като конвенция, а не като част от програмния език. Типично се връщаше стойност и се слагаше флаг, като се предполагаше, че по­лу­чателят ще провери флага и ще изследва стойността за да разбере про­бле­ма. Обаче с течение на годините стана ясно, че програмистите които правят би­блио­теките имат тенденция да се считат за непобедими, както в: “Да, грешки мо­­гат да се появят при другите но не и в моя код.” Така, не много изненадващо, те не правеха нужните проверки (а и понякога ситуациите на грешка бяха твър­де тъпи за да се проверява за тях¹). Ако бяхте достатъчно последователни да про­верявате за грешки всеки път като извикате метод, вашият код рискуваше да се превърне в нечитаем кошмар. Понеже програмистите трябваше да се се опра­вят с тези програмни системи те упорито поддържаха че: Този подход към обра­ботката на грешки е главното ограничение пред правенето на добри, го­ле­ми, управляеми програми.

Решението е да се разкара решаването на въпросите според случая от обра­бот­ка­та на грешки и да се въведе формализъм. Това фактически има дълга история, по­неже реализации на поддръжка на изключения се отнасят и за операционни си­стеми от 1960-те години и даже за on error goto на BASIC. Но поддръжката на изключения в C++ беше базирана на тази в Ada, а в Java е основана пре­дим­но на C++ (макар и повече да изглежда на Object Pascal).

Думата “exception” се има пред вид в значението “Вземам изключение за нещо.” В точката на възникване на проблема би могло да не се знае какво да се пра­ви с него, но се знае, че не може просто весело да се продължи; трябва да се спре и някой, някъде, трябва да изясни какво ще се прави. Но вие нямате ин­фор­мация в текущия момент за решаване на проблема. Така че представяте про­блема в по-висок контекст така че някой с нужната информация ще вземе мер­ките (доста подобно на веригата от команди (при командването на нещо, на­пример кораб-бел.пр.)).

Другата голяма полза от поддържането на изключенията е че те очистват кода. Наместо да се проверява за конкретна грешка и това да се прави в няколко ме­ста в програмата, повече няма да се проверява в точката на извикване на ме­то­да (понеже изключението гарантира, че някой ще го хване). Необходимо е да се обра­боти проблема само в едно място, тъй наречения exception handler. Това спе­стява писане и разделя кода за нещата които трябва да се правят от този кой­то е за в случай че се развали нещо. Изобщо да се пише, чете и тества код ста­ва много по-ясно като се използват изключения, отколкото по стария начин.

Понеже поддръжката на изключения се налага от компилатора на Java, има тол­ко­ва много примери в тази книга които могат да се напишат без знание на по­дроб­ности. Тази глава ви въвежда в нещата, които позволяват да напишете код за правилна обработка на изключенията, а също и как да генерирате свои соб­стве­ни изключения, ако ваш метод има неприятности.