Рубрика «обработка ошибок» - 3

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

Три пользовательских интерфейса заходят в паб. Первый заказывает напиток, затем ещё несколько. Парой часов позже он просит счёт и покидает паб пьяным. Второй заказывает напиток, платит за него сразу же, заказывает ещё один, платит за него, продолжает в том же духе, и через пару часов покидает паб пьяным. А третий заходит в паб уже пьяным — он знает, как работают пабы, и достаточно эффективен, чтобы не терять время. Слышали об этом третьем? Его называют «оптимистичным UI».

Правдивая ложь оптимистичных интерфейсов - 1

Оптимистичный подход к UI не в том, чтобы смотреть на веб через розовые очки — по крайней мере, не только в этом.
Читать полностью »

Предлагаю вашему вниманию перевод статьи "Replace Throw With Notification" Мартина Фаулера. Примеры адаптированы под .NET.

Если мы валидируем данные, обычно мы не должны использовать исключения, чтобы известить о валидационных ошибках. Здесь я опишу как отрефакторить такой код с использованием паттерна «Уведомление» («Notification»).

Замена выброса исключений уведомлениями - 1

Недавно я смотрел на код, который делал базовую валидацию входящих JSON сообщений. Это выглядело примерно так…
Читать полностью »

Если спросить среднестатического Go-девелопера, какие есть преимущества у Go — скорее всего вы услышите уже знакомый перечень плюшек. О них уже написано немало, но очень часто обходится стороной другая вещь, гораздо более интересная — долгосрочный эффект тех или иных решений дизайна языка. Я хочу раскрыть эту тему чуть шире, которая на самом деле актуальна не только для Go. Но в данной статье я возьму для примера два аспекта — способ обработки ошибок в Go и систему тестирования и постараюсь показать, как дизайн языка вынуждает людей более писать более качественный код.

Главное преимущество Go - 1
Читать полностью »

Если издали видно общую картину, то вблизи можно понять суть. Концепции, которые казались мне далекими и, прямо скажем, странными во время экспериментов с 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 вообще не существует, поскольку он прячет под капотом всю работу с указателями. Остальные два пункта решаются с помощью перечислений.Читать полностью »

Американский веб-разработчик Мэтт Даймонд (Matt Diamond) написал плагин JavaScript под названием FuckItJS. Если вставить в код метод FuckIt, то он заставит исполняться самый плохой скрипт, «нравится это компилятору или нет».

В общем, FuckItJS работает так: из скрипта вырезаются все строчки, на которые выскочили ошибки. Затем процесс повторяется заново, пока скрипт (или что там от него осталось) не проходит компиляцию без ошибок. Чтобы выжить в этом жестоком мире, FuckItJS перезагружается после каждой итерации.
Читать полностью »

Однажды, перейдя по очередной ссылке t.co на ссылку vk.cc, которая вела на ссылку ow.ly на youtu.be, я задумался, а что мне скажет браузер, если я предложу ему ссылку, ссылающуюся на ссылку, ссылающуюся обратно?
Читать полностью »

На написание данной статьи-заметки меня сподвигла работа на формой обратной связи, в которой имелась возможность отправки файлов на сервер. Естественным образом захотелось ограничить размер загружаемых файлов со стороны сервера и выдавать пользователю соответствующее сообщение. Хорошая новость заключалась в том, что ASP.NET имеет встроенные средства для такого ограничения. Плохая – нет лёгких путей обработки данной ситуации.

Читать полностью »

ASP.NET MVC / Обработка всех исключений в контроллерах с помощью атрибута
Всё мы знаем, что в ASP.NET MVC есть такой атрибут HandleErrorAttribute, который как сказано в MSDN

Представляет атрибут, используемый для обработки исключения, вызываемого методом действия.
Но нигде, в том же MSDN не сказано (ткните меня носом дайте ссылку где это написано, если я просмотрел), что он обрабатывает только исключения, устанавливающие код ответа сервера в 500.
Посмотрев на исходный код HandleErrorAttribute легко убедиться в этом. Там имеются следующие строки:
// If this is not an HTTP 500 (for example, if somebody throws an HTTP 404 from an action method),
// ignore it.
if (new HttpException(null, exception).GetHttpCode() != 500) {
return;
}

Не знаю, как вам, а мне удобнее при возникновенииЧитать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js