Гарне використання пробних фільмів?

Мені завжди доводиться боротися з цим ... намагаючись знайти правильний баланс між спробою / ловом і кодом, що не стає цим нецензурним безладдям вкладок, дужок та винятків, що повертаються назад до стека викликів, як гаряча картопля. Наприклад, у мене є програма, яку я зараз розробляю, яка використовує SQLite. У мене є інтерфейс Бази даних, який абстрагує дзвінки SQLite, і Модель, яка приймає речі для входу / виходу з бази даних ... Отже, якщо / коли виникає виняток SQLite, він повинен перейти до Моделі (хто його назвав ), хто повинен передати це тому, хто назвав AddRecord / DeleteRecord / що завгодно ...  

Я прихильник винятків, не повертали коди помилок , тому що коди помилок можуть бути проігноровані, забуті, і т.д., в той час як виняток , за суті має бути оброблено ( як належне, я міг би зловити і перейти відразу ...) Я певне, що має бути кращий спосіб, ніж те, що я зараз відбуваю.

Редагувати:  я повинен був би сформулювати це дещо інакше. Я розумію, що потрібно перекидати як різні типи і подібні, я це дуже погано висловив, і це моя вина. Моє запитання: як найкраще зберегти чистий код, роблячи це? Він просто починає відчувати себе надзвичайно захаращеним через деякий час.

Подумайте про це з точки зору сильного введення тексту, навіть якщо ви не використовуєте сильно набрану мову - якщо ваш метод не може повернути той тип, який ви очікували, він повинен бути винятком.

Крім того, замість того, щоб перекидати SQLException аж до моделі (або, що ще гірше, інтерфейс користувача), кожен шар повинен фіксувати відомі винятки та обертати / мутувати / замінювати їх винятками, відповідними цьому шару:

Layer      Handles Exception
----------------------------
UI         DataNotFoundException
Model      DatabaseRetrievalException
DAO        SQLException

Це має допомогти обмежити кількість винятків, які ви шукаєте в кожному шарі, і допомогти вам підтримувати організовану систему виключень.

Винятки дозволяють писати чистіший код, оскільки основна частина цього стосується звичайного випадку, а виняткові випадки можуть бути вирішені пізніше, навіть у іншому контексті.

Правило поводження (вилучення) винятків полягає в тому, що це потрібно робити за контекстом, який насправді може щось робити. Але це має вихід:

Винятки повинні бути укладені на межі модулів (особливо межі шарів), і навіть якщо тільки для того, щоб укласти їх, кинути виняток вищого рівня, який має значення для абонента. Кожен модуль і шар повинні приховувати деталі своєї реалізації навіть щодо винятків (модуль купи може кидати HeapFull, але ніколи ArrayIndexOutOfBounds).

У вашому прикладі навряд чи верхні шари можуть зробити що-небудь щодо виключення SQLite (якщо вони є, то це все так поєднано з SQLite, що ви не зможете переключити рівень даних на щось інше). Існує декілька передбачуваних причин, коли такі речі, як Додати / Видалити / Оновити, не вдасться, і деякі з них (несумісні зміни в одночасних транзакціях) неможливо відновити навіть у шарі даних / постійності (порушення правил цілісності, fi). Шар стійкості повинен переводити винятки на щось значуще в умовах модельного шару, щоб верхні шари могли вирішити, чи потрібно повторно намагатись або вийти з ладу.

Як правило, ви повинні ловити лише конкретні винятки (наприклад, IOException), і лише якщо у вас є щось конкретне, щойно ви зробили виняток.

В іншому випадку, найкраще, щоб Винятки пустили на поверхню, щоб їх можна було піддавати впливу та поводження з ними. Деякі люди називають це невдалим.

У вас має бути якийсь обробник у корені вашої програми, щоб ловити необроблені Винятки, які піднялися знизу. Це надає вам можливість представити, звітувати або керувати Винятком належним чином.

Обгортання винятків корисно, коли вам потрібно перенести виняток у розподілену систему, і у клієнта немає визначення помилки на сервері.

Уявіть, що ви пишете клас стека. Ви не кладете жодного коду обробки винятків у класі, у результаті він може створити наступні винятки.

1. ArrayIndexError - піднімається, коли користувач намагається вискочити з порожнього стека
2. NullPtrException - піднімається через помилку в реалізації, що викликає спробу посилання на нульову посилання

Спрощений підхід до загортання винятків може вирішити перетворити обидва ці винятки в клас виключень StackError. Однак, це дійсно не вистачає суті обговорення винятків. Якщо об’єкт кидає виняток низького рівня, це повинно означати, що об'єкт порушений. Однак є один випадок, коли це прийнятно: коли об’єкт насправді розбитий.

Сенс обговорення винятків полягає в тому, що об’єкт повинен створювати належні винятки для звичайних помилок. Стек повинен підняти StackEmpty не ArrayIndexError, коли з'являється з порожнього стека. Намір не уникнути викидання інших винятків, якщо об’єкт або код порушені.

Чого ми насправді хочемо уникнути, це ловити винятки низького рівня, які передаються через об'єкти високого рівня. Клас стека, який викидає ArrayIndexError при вискакуванні з порожнього стека, є незначною проблемою. Якщо ви насправді зловили цей ArrayIndexError, тоді у нас є серйозна проблема. Розповсюдження помилок низького рівня є набагато менш серйозним гріхом, ніж їх наздоганяти.

Щоб повернути це до вашого прикладу SQLException: чому ви отримуєте SQLExceptions? Одна з причин - ви передаєте недійсні запити. Однак якщо ваш рівень доступу до даних генерує погані запити, його помилка. Він не повинен намагатися перетворити свою зламаність у виняток DataAccessFailure.

Однак SQLException також може виникнути через втрату зв'язку з базою даних. Моя стратегія з цього приводу полягає в тому, щоб зафіксувати виняток на останній лінії захисту, повідомити користувачеві про втрату підключення до бази даних та відключення. Оскільки програма має доступ до бази даних втрат, то насправді можна зробити не набагато більше.

Я не знаю, як виглядає ваш код. Але це здається, що ви можете сліпо перекладати всі винятки у винятки вищого рівня. Ви повинні робити це лише у відносно невеликій кількості випадків. Більшість винятків нижчого рівня вказують на помилки у вашому коді. Ловля та перемотування їх контрпродуктивна.