image
Частини 1 і 2: посилання
У першій частині ми поговорили про різних стратегіях обробки помилок і про те, коли їх рекомендується застосовувати. Зокрема, я розповів, що передумови функцій повинні перевірятися з допомогою налагоджувальних тверджень (debug assertions), тобто тільки в режимі налагодження.
Для перевірки умови бібліотека З надає макрос
assert()
, але тільки якщо не визначено
NDEBUG
. Однак, як і у випадку з багатьма іншими речами, це просте, але іноді неефективне рішення. Головна проблема, з якою я зіткнувся, — глобальність рішення: у вас є твердження або скрізь, або ніде. Погано це тому, що ви не зможете вимкнути затвердження в бібліотеці, залишивши їх тільки у власному коді. Тому багато авторів бібліотек самостійно пишуть макроси тверджень, раз за разом.
Читати далі →



Існує дві основні стратегії: обробка виправних помилок (виключення, коди повернення помилково, функції-обробники) і невиправних (
assert()
,
abort()
). В яких випадках яку стратегію краще використовувати?

Читати далі →

Введення в обробку помилок в Swift 3

Сьогодні ми підготували переклад для тих, хто так само, як автор статті, при вивченні Документації мови програмування Swift уникає голови «Error Handling».

Зі статті ви дізнаєтеся:

  • що таке оператор if-else і що з ним не так;
  • як подружитися з Error Handling;
  • коли варто використовувати Try! і Try?


Читати далі →

Правдива брехня оптимістичних інтерфейсів

Нещодавно опублікована у Smashing Magazine стаття Дениса Мишунова здалася нам дуже цікавою: вона присвячена підходу, про який багато хто до цих пір не замислюються, хоча він вже оточує нас в популярних сервісах. З дозволу автора і першоджерела ми вирішили перевести цей матеріал для хабрасообщества.

Три користувача інтерфейсу заходять в паб. Перший замовляє напій, потім ще кілька. Парою годин пізніше він просить рахунок і залишає паб п'яним. Другий замовляє напій, платить за нього відразу ж, замовляє ще один, сплачує за нього, продовжує в тому ж дусі, і через пару годин покидає паб п'яним. А третій заходить в паб вже п'яним, він знає, як працюють паби, і досить ефективний, щоб не втрачати час. Чули про це третьому? Його називають оптимістичним UI».



Оптимістичний підхід до UI не в тому, щоб дивитися на веб через рожеві окуляри — принаймні, не лишев цьому.

Читати далі →

Роздуми про способи обробки помилок

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

Код у статті наводиться на scala, однак розглянутий підхід може бути реалізований на багатьох інших мовах (c++ за допомогою макросів, java з допомогою JetBrains MPS і т. д.). Найбільш близьким аналогом розглянутого підходу є спосіб обробки помилок в haskell.

Читати далі →

Головна перевага Go

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



Читати далі →

Обробка помилок в Swift - меч і магія

Якщо здалеку видно загальну картину, то поблизу можна зрозуміти суть. Концепції, які здавалися мені далекими і, прямо скажемо, дивними під час експериментів з Haskell і Scala, при програмуванні на Swift стають сліпуче очевидними рішеннями для широкого спектру проблем.

Взяти ось обробку помилок. Конкретний приклад — ділення двох чисел, яке повинно викликати виключення якщо дільник дорівнює нулю. В Objective C я б вирішив проблему так:

NSError *err = nil;
CGFloat result = [NMArithmetic divide:2.5 by:3.0 error:&err];
if (err) {
NSLog(@"%@", err)
} else {
[NMArithmetic doSomethingWithResult:result]
}

З часом це стало здаватися самим звичним способом написання коду. Я не помічаю, які закарлюки доводиться писати і побічно вони пов'язані з тим, що я насправді хочу від програми:

Поверни мені значення. Якщо не вийде — то дай знати, щоб помилки можна було обробити.

Я передаю параметри, разыменовываю покажчики, повертаю значення в будь-якому випадку і в деяких випадках потім ігнорую. Це неорганізований код з наступних причин:

  • Я кажу на машинній мові — покажчики, розіменування.
  • Я повинен сам надати методом спосіб, яким він повідомить мене про помилку.
  • Метод повертає деякий результат навіть у разі помилки.
Кожен з цих пунктів — джерело можливих помилок, і всі ці проблеми Swift вирішує по-своєму. Перший пункт, наприклад, Swift взагалі не існує, оскільки він ховає під капотом всю роботу з покажчиками. Інші два пункти вирішуються з допомогою перерахувань.
Читати далі →