Exception что это значит

Многие программисты почему-то считают, что исключения и ошибки — это одно и то же. Кто-то постоянно кидает exception, кто-то через errorHandler превращает ошибки в исключения. Некоторые пытаются увеличить производительность, используя исключения. Но, на самом деле, exception и ошибки — это совершенно разные механизмы. Не надо одним механизмом заменять другой. Они созданы для разных целей.

Когда появился php5 с исключениями, а затем ZendFramework, который всегда кидает исключения — я не мог понять: чем же exception лучше моего любимого trigger_error()? Долго думал, обсуждал с коллегами и разобрался в этом вопросе. Теперь я чётко знаю, где использовать trigger_error(), а где throw new Exception().

В чём же принципиальная разница между ними?

Ошибки

Ошибки — это то, что нельзя исправить, об этом можно только сообщить: записать в лог, отправить email разработчику и извинится перед пользователем. Например, если мой движок не может подключиться к БД, то это ошибка. Всё. Точка. Без БД сайт не работает, и я не могу с этим ничего сделать. Поэтому я вызываю ales_kaput() и trigger_error(), а мой errorHandler отправит мне email и покажет посетителю сообщение «Извините, сайт не работает».

Exception

Исключения — это не ошибки, это всего лишь особые ситуации, которые нужно как-то обработать. Например, если в калькуляторе вы попробуете разделить на ноль, то калькулятор не зависнет, не будет отсылать сообщения разработчику и извинятся перед вами. Такие ситуации можно обрабатывать обычным if-ом. Строго говоря, исключения — это конструкция языка позволяющая управлять потоком выполнения. Это конструкция, стоящая в одном ряду с if, for и return. И всё. Этот механизм ничем более не является. Только управление потоком.

Их основное предназначение: пробрасывать по каскаду. Покажу это на примере: есть три функции, которые вызывают друг друга каскадом:

Эту задачу можно было бы решить без механизма exception. Например, можно заставить все функции возвращать специальный тип (если ты матёрый пэхапэшник, то должен вспомнить PEAR_Error). Для простоты я обойдусь null-ом:

Задача выполнена, но, обратите внимание, мне пришлось модифицировать промежуточную функцию b(), чтобы она пробрасывала результат работы нижестоящей функции выше по каскаду. А если у меня каскад из 5 или 10 функций? То мне пришлось бы модифицировать ВСЕ промежуточные функции. А если исключительная ситуация в конструкторе? То мне пришлось бы подставлять костыли.

А теперь решение с использованием Exception:

Таким образом, получается, что ошибки и исключения — это совершенно разные инструменты для решения совершенно разных задач:
ошибка — не поправимая ситуация;
исключение – позволяет прервать выполнение каскада функций и пробросить некоторую информацию. Что-то вроде глобального оператора return. Если у Вас нет каскада, то вам достаточно использовать if или return.

Ошибки не всегда являются ошибками

Некоторые могут мне возразить: «Посмотри в Zend Framework — там всегда кидают исключения. Это best practics, и надо делать также. Даже если не удалось подключиться к БД, надо кидать исключение».

В этой статье я как раз хочу развеять это заблуждение. Zend действительно является best practics, но программисты Зенда находятся на другой лодке и делают другие вещи. Принципиальная разница между ними и мной в том, что они пишут универсальную библиотеку, которая будет использоваться во многих проектах. И они со своей колокольни не могут сказать, что является критической ошибкой, а что является поправимой.

Например, в вашем проекте может быть несколько MySQL серверов и вы можете переключаться между ними при падении одного из них. По этому, Zend_Db, как универсальная библиотека, кидает исключение, а что с ним делать — решайте сами. Exception это гибко — вы сами решаете на каком уровне и какой тип ситуаций ловить. Вы можете вывести сообщение об ошибке или попытаться исправить возникшую ситуацию, если знаете как. При написании универсальных библиотек необходимо всегда кидать исключения. Это делает библиотеку более гибкой.

В php давно был разработан механизм обработки ошибок, и он отлично работает. Я им отлично пользуюсь там, где это надо.

Источник

существительное ↓

Мои примеры

Словосочетания

Примеры

Unfortunately there is an exception to every rule.

К сожалению, для каждого правила существует исключение.

I’ll make an exception this once.

В этот раз я сделаю исключение.

It’s been cold, but today’s an exception.

Погода стоит холодная, но сегодня — исключение.

There will be no exceptions to this rule.

Никаких исключений из этого правила не будет.

The sanitary conditions were, without exception, infamous.

Санитарные условия были в целом ужасными.

Each plant, without exception, contains some kind of salt.

Все растения, без исключений, содержат какой-либо вид соли.

She suggested (to us) that an exception be / should be made.

Она пыталась нас убедить в том, что должно быть сделано исключение.

I take strong exception to your assessment of his singing ability.

Я решительно возражаю против вашей оценки его певческого таланта.

The spelling of this word is an interesting exception to the rule.

Написание этого слова является интересным исключением из правил.

Tom took great exception to my remark about Americans.

Тома очень обидело моё замечание по поводу американцев.

The possession of the gift was the rule and not the exception.

Обладание талантом было правилом, а не исключением.

A series of payments used to be the exception rather than the rule.

Раньше серия платежей была скорее исключением, чем правилом.

Even in Africa, the chief centre of polygynous habits, polygyny is an exception.

With a few minor exceptions, the new edition is much like the previous one.

За небольшими исключениями, новое издание во многом похоже на предыдущее.

We don’t usually accept checks, but for you we’ll make an exception (=not include you in this rule).

Как правило, мы не принимаем чеки, но для вас мы сделаем исключение (т.е. не станем включать вас в это правило).

Violence is the rule not the exception.

Насилие является правилом, а не исключением.

Without exception, book reviewers reprehended the novel’s tired plot.

Все без исключения рецензенты данного романа осудили его скучный и банальный сюжет.

Most people here are very dedicated; I’m afraid Rhea’s the exception that proves the rule.

Большинство здешних людей очень преданны. К сожалению, Рея — исключение, которое подтверждает правило.

Successful two-career couples are still the exception, not the rule (=used to emphasize that something is unusual).

Пары, в которых каждый из супругов сделал успешную карьеру, по-прежнему являются исключением, а не правилом (данное выражение используется, чтобы подчеркнуть нечто необычное).

Примеры, ожидающие перевода

We all laughed, with the exception of Maggie.

The law applies to all EU countries; Britain is no exception.

With one or two notable exceptions, there are few women conductors.

Источник

exception

1 EXCEPTION

2 exception

3 exception

исключение, изъятие, предусмотренное в законе изъятие (часть статьи закона, начинающаяся словом except)

исключение;
the exception proves the rule исключение подтверждает правило;
with the exception of. за исключением.

обида;
to take exception (at) обижаться, оскорбляться (на)

исключение;
the exception proves the rule исключение подтверждает правило;
with the exception of. за исключением. general

вчт. исключение по значимости exception возражение;
to take exception (to smth.) возражать (против чего-л.)

обида;
to take exception (at) обижаться, оскорбляться (на) take

to возражать против

исключение;
the exception proves the rule исключение подтверждает правило;
with the exception of. за исключением. without

4 exception

to be beyond exception — не вызывать никаких возражений ; не подлежать сомнению

bill of exceptions — жалоба стороны в вышестоящий суд на то, что нижестоящий суд не принял во внимание сделанных ею заявлений о допущенных ошибках

Exception, Your Honour! — возражение, Ваша честь!

5 exception

6 exception

7 exception

to bring in an exception against — выступать против; делать отвод (кандидату и т.п.)

to take exception to / against a witness — юр. отводить свидетеля

8 exception

exception to bail — возражение истца против размера поручительства за уплату присуждённой суммы;

9 exception

10 exception

исключение
Информация о соединениях в сложном представлении узла PNNI, содержащая нечто отличное от используемого по умолчанию представления.
[ http://www.lexikon.ru/dict/net/index.html]

Тематики

исключение документов
рекомплектование
Отбор, изъятие из фонда и снятие с учета непрофильных, устаревших, излишне дублетных, ветхих документов, а также снятие с учета утраченных документов.
[ГОСТ 7.76-96]

Тематики

Синонимы

исключительная ситуация
Совокупность определенных условий, возникновение которых приводит к нарушению предусмотренной последовательности выполнения в программе.
[ ГОСТ 28397-89]

Тематики

исключительный случай
особая ситуация
—
[А.С.Гольдберг. Англо-русский энергетический словарь. 2006 г.]

Тематики

Синонимы

освобождение (от требований)
Термины освобождение и освобожденный употребляются в отдельных случаях, когда некоторые требования или руководящие материалы, содержащиеся в нормах безопасности, могут не применяться. В этом отношении освобождение можно сравнить с изъятием и исключением . Однако изъятие и исключение обязательно обусловлены конкретными причинами неприменения правил или требований, в то время как освобождение не имеет такой привязки. Фактически это – обычное употребление англоязычного термина exception в смысле исключения, а не узкоспециализированный термин. Термин освобожденная упаковка в Правилах перевозки является примером этого употребления; упаковки могут освобождаться от установленных требований Правил перевозки, если они удовлетворяют условиям, определенным в Правилах перевозки.
[Глоссарий МАГАТЭ по вопросам безопасности]

Тематики

особый случай
исключение
Альтернативное название прерывания, используемое некоторыми изготовителями микропроцессоров.
[Е.С.Алексеев, А.А.Мячев. Англо-русский толковый словарь по системотехнике ЭВМ. Москва 1993]

Тематики

Синонимы

Совокупность определенных условий, возникновение которых приводит к нарушению предусмотренной последовательности выполнения в программе

11 exception

12 exception

13 exception

Exceptions can be any condition that causes normal operation to be interrupted, such as interrupts, arithmetic overflow, and bus errors. — Исключениями могут быть любые ситуации, вызывающие изменение нормального режима работы, например прерывания, арифметические переполнения и ошибки шины см. тж. error trapping, exception declaration, exception handler, exception message, overflow, software, underflow, unhandled exception

14 exception

to make an exception for smth. / smb. — делать исключение для кого-л. / чего-л.

an exception from / to the rule — исключение из правила

The possession of the gift was the rule and not the exception. — Обладание талантом было правилом, а не исключением.

15 exception

16 exception

17 exception

18 exception

19 exception

20 exception

См. также в других словарях:

exception — [ ɛksɛpsjɔ̃ ] n. f. • 1243 dr.; lat. exceptio, de excipere « retirer, excepter » → exciper 1 ♦ Action d excepter. Il ne sera fait aucune exception à cette consigne. ⇒ dérogation, restriction. Faire une exception pour qqn, en faveur de qqn. Faire… … Encyclopédie Universelle

exception — ex·cep·tion n 1: something that is excepted or excluded; esp: a situation to which a rule does not apply the supreme Court shall have appellate jurisdiction, both as to law and fact, with such exception s, and under such regulations as the… … Law dictionary

exception — Exception. s. f. v. L action par laquelle on excepte. Faire exception, une exception, sans exception. n y a t il point d exception? il n y a regle si generale qui n ait son exception. cela ne souffre point d exception. l exception confirme la… … Dictionnaire de l’Académie française

exception — et clause qui borne une generalité, Exceptio. Bailler exception, Dare exceptionem. Bailler toute puissance et authorité sans aucune exception, Infinitum imperium dare alicui, B. Ceste exception arreste le demandeur tout court, Haec obiecta… … Thresor de la langue françoyse

exception — [ek sep′shən, iksep′shən] n. [ME excepcioun < OFr exception < L exceptio] 1. an excepting or being excepted; omission; exclusion 2. anything that is excepted; specif., a) a case to which a rule, general principle, etc. does not apply b) a… … English World dictionary

exception — late 14c., from Anglo Fr. excepcioun, O.Fr. excepcion, from L. exceptionem (nom. exceptio), noun of action from pp. stem of excipere (see EXCEPT (Cf. except)). The exception that proves the rule is from law: exceptio probat regulam in casibus non … Etymology dictionary

exception — ► NOUN 1) a person or thing that is excepted or that does not follow a rule. 2) the action of excepting or the state of being excepted. ● the exception proves the rule Cf. ↑the exception proves the rule ● take exception to Cf. ↑ta … English terms dictionary

Exception — Ex*cep tion ([e^]k*s[e^]p sh[u^]n), n. [L. exceptio: cf. F. exception.] 1. The act of excepting or excluding; exclusion; restriction by taking out something which would otherwise be included, as in a class, statement, rule. [1913 Webster] 2. That … The Collaborative International Dictionary of English

exception — The proverb the exception proves the rule means ‘the existence of an exception shows that a rule exists in those cases that are not exceptions’. It should not be used to mean ‘the exception becomes the rule’, although this is often found … Modern English usage

Exception — may refer to: * An action that is not part of ordinary operations or standards * exception handling * Exception (song), the second single from Ana Johnsson s second album Little Angel *Exceptional Records … Wikipedia

exception — [n1] leaving out barring, debarment, disallowment, excepting, exclusion, excusing, expulsion, noninclusion, omission, passing over, rejection, repudiation, reservation; concepts 25,30,211 Ant. admittal, admittance, allowance, inclusion exception… … New thesaurus

Источник

Правильное использование Exception’ов в PHP

Я рад бы написать что “эта статья предназначена для новичков”, но это не так. Большинство php-разработчиков, имея опыт 3, 5 и даже 7 лет, абсолютно не понимают как правильно использовать эксепшены. Нет, они прекрасно знают о их существовании, о том что их можно создавать, обрабатывать, и т.п., но они не осознают их удобность, логичность, и не воспринимают их как абсолютно нормальный элемент разработки.

Почему мы не умеем пользоваться эксепшенами:

PHP — это чрезмерно любящая мать. И при отсутствии строгого отца (например, Java ) или самодисциплины, разработчик вырастет эгоистом, которому плевать на все правила, стандарты и лучшие практики. И вроде бы E_NOTICE пора включать, а он все на мать надеется. Которая, между прочим, стареет — ей уже E_STRICT c E_DEPRICATED нужны, а сынуля все на шее висит.

И пока наш начинающий разработчик пытается написать свою первую быдло-cms, он ни разу не встретиться с механизмом эксепшенов. Вместо этого, он придумает несколько способов обработки ошибок. Я думаю, все понимают о чем я — эти методы, возвращающие разные типы (например, объект при успешном выполнении, а при неудаче — строка с ошибкой), или запись ошибки в какую-либо переменную/свойство, и всегда — куча проверок чтоб передать ошибку вверх по стеку вызовов.

Затем он научиться отлавливать и обрабатывать их. И на этом его знакомство c эксепшенами закончиться. Ведь надо работать, а не учиться: знаний ему и так хватает (сарказм)!

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

Преимущества эксепшенов

На самом деле использование эксепшенов — крайне лаконичное и удобное решение создания и обработки ошибок. Приведу наиболее значимые преимущества:

Контекстная логика

Прежде всего, хотелось бы показать что эксепшн — это не всегда только ошибка (как обычно ее воспринимают разработчики). Иногда он может быть частью логики.

Например, есть у нас функция чтения JSON объекта из файла:

Допустим мы пытаемся прочитать какие-то ранее загруженные данные. При такой операции эксепшн FileNotFoundException не является ошибкой и вполне допустим: возможно, мы ни разу не загружали данные, поэтому файла и нет. А вот JsonParseException — это уже признак ошибки, ибо данные были заргужены, обработаны, сохранены в файл, но почему-то сохранились не правильно.

Совсем другое дело, когда мы пытаемся прочитать файл, который должен быть всегда: при такой операции FileNotFoundException так же является сигналом ошибки.

Таким образом, эксепшены позволяют нам определять логику их обработки в зависимости от контекста, что очень удобно.

Упрощение логики и архитектуры приложения

Попробуйте использовать эксепшены, и вы увидите как ваш код станет более лаконичным и понятным. Исчезнут все костыльные механизмы, возможно, уберутся куча вложенных if’ов, различные механизмы передачи ошибки вверх по стеку вызова, логика станет более простой и прямолинейной.

Места вызовы эксепшенов помогут вашему коллеге лучше понять бизнес логику и предметную область, ибо копаясь в вашем коде он сразу увидит что допустимо, а что нет.

И, если рассматривать какой-либо самодостаточный кусок кода, например, компонента, то список бросаемых им эксепшенов выполняет еще одну важную вещь: дополняет интерфейс этого компонента.

Пользуясь сторонними компонентами мы привыкли обращать внимание только на положительную сторону — на то, что он умеет. При этом обычно не думаем о исключениях, которые он может создать в процессе работы. Список эксепшенов сразу предупреждает где, когда, и какие проблемы могут возникнуть. А предупрежден — значит вооружен.

Вот пример информативного интерфейса, который дополнен знаниями об эксепшенах:

Использование объектов

Использование определенного класса в качестве ошибки — очень удобное решение. Во первых, класс невозможно перепутать: взгляните на 2 способа обработки ошибки:

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

Второе преимущество — класс эксепшена инкапсулирует все необходимые данные для его обработки. Например, AddressNotFoundException мог бы выглядеть следующим образом:

Как видим — эксепшн содержит адрес, который не удалось найти. Обработчик может его получить и выполнить на основании его какую-то свою логику.

Третье преимущество — это, собственно, все преимущества ООП. Хотя эксепшены, как правило, простые объекты, поэтому возможности ООП мало используются, но используются.

Например, у меня в приложении порядка 70 классов эксепшенов. Из них несколько — базовых — по одному классу на модуль. Все остальные — наследуются от базового класса своего модуля. Сделано это для удобства анализа логов.

Так же я использую несколько ИНТЕРФЕЙС-МАРКЕРОВ:

Обработчик по умолчанию, логирование

Этот обработчик позволяет нам выполнить различные действия перед остановкой скрипта. Самое главное что нужно сделать, это:

Откат изменений: так как операция не выполнена до конца, необходимо откатить все сделанные изменения. В противном случае мы испортим данные. Например, можно в CController::beforeAction() открыть транзакцию, в CController::afterAction() коммитить, а в случае ошибки сделать роллбэк в обработчике по умолчанию.

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

Получается что мы откатили изменения и бросили тот же эксепшн, что продолжить его обработку.

Логирование: так же обработчик по умолчанию позволяет нам выполнить какое-то кастомное логирование. Например, в моем приложении я все складываю в базу и использую собственное средство для анализа. На работе мы используем getsentry.com/welcome. В любом случае, эксепшн, дошедший до обработчика по умолчанию — скорее всего непредусмотренный эксепшн, и его необходимо логировать. Следует отметить, что в класс эксепшена можно добавить различную информацию, которую необходимо логировать для большего понимания причины возникновения ошибки.

Невозможность не заметить и перепутать

Огромным плюсом эксепшена является его однозначность: его не возможно не заметить и не возможно с чем-то спутать.

Из первого следует что мы всегда будем осведомлены о возникшей ошибке. И это замечательно — всегда лучше знать о проблеме, чем не знать.

Второй плюс становится очевиден в сравнении с кастомными методами обработки ошибки, например когда метод возвращает null если не нашла нужный объект и false в случае ошибки. В таком случае элементарно не заметить ошибку:

Эксепшн же невозможно пропустить.

Прекращение ошибочной операции

Но самое главное, и самое важное, что делает эксепшн — это прекращает дальнейшее выполнение операции. Операции, которая уже пошла не так. И, следовательно, результат которой непредсказуем.

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

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

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

Когда следует вызывать эксепшены:

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

Встает вопрос: в каких ситуациях стоит вызывать эксепшн?

Если кратко — всегда! Если подробно: всегда, когда ты уверен что операция должна выполниться нормально, но что-то пошло не так, и ты не знаешь что с этим делать.

Посмотрим на простейший экшн добавления записи:

Когда мы введем некорректные данные поста эксепшн не вызывается. И это вполне соответствует формуле:

Сама кнопка отмены показывается только тогда, когда заказ возможно отменить. Таким образом, когда вызывается этот метод, я уверен, что операция должна пройти успешно (в противном случае кнопка бы не отобразилась, и пользователь не смог бы нажать на нее для вызова этого метода).

Первым делом идет предвалидация — мы проверяем действительно ли мы можем выполнить операцию. В теории все должно пройти успешно, но если isAllowedStatus вернет false — значит что-то пошло не так. Плюс, в пределах текущего метода, мы абсолютно не знаем как обработать эту ситуацию. Понятно, что нужно залогировать ошибку, вывести ее пользователю, и т.п… Но в контексте именно этого метода мы не знаем что с ней делать. Поэтому бросаем эксепшн.

Далее идет выполнение операции и сохранение изменений.

Затем идет поствалидация — мы проверяем, действительно ли все сохранилось, и действительно ли статус изменился. На первый взгляд это может показаться бессмысленным, но: заказ вполне мог не сохранится (например, не прошел валидацию), а статус вполне мог быть изменен (например, кто-то набыдлокодил в CActiveRecord::beforeSave ). Поэтому эти действия необходимы, и, опять-таки, если что-то пошло не так — бросаем эксепшн, так как в пределах данного метода мы не знаем как обрабатывать эти ошибки.

Эксепшн vs возврат null

Следует отметить, что эксепшн следует бросать только в случае ошибки. Я видел как некоторые разработчики злоупотребляют ими, бросая их там, где не следовало бы. Особенно часто — когда метод возвращает объект: если не получается вернуть объект — бросается эксепшн.

Тут следует обратить внимание на обязанности метода. Например, СActiveRecord::find() не бросает эксепшн, и это логично — уровень его “знаний” не содержит информации о том, является ли ошибкой отсутствие результата. Другое дело, например, метод KladrService::resolveAddress() который в любом случае обязан вернуть объект адреса (иначе либо код неправильный, либо база не актуальная). В таком случае нужно бросать эксепшн, ибо отсутствие результата — это ошибка.

В целом же, описанная формула идеально определяет места, где необходимо бросать эксепшены. Но особо хотелось бы выделить 2 категории эксепшенов, которых нужно делать как можно больше:

Технические эксепшены

Это эксепшены, которые абсолютно не связанны с предметной областью, и необходимы чтобы чисто технически предотвратить выполнение неверной логики.

Вот несколько примеров:

Технические эксепшены помогут не допустить или отловить, имхо, большую часть багов в любом проекте. И неоспоримым плюсом их использования является отсутствие необходимости понимать предметную область: единственное что требуется — это дисциплина разработчика. Я призываю не лениться и вставлять такие проверки повсеместно.

Эксепшены утверждений

Эксепшены утверждений (по мотивам DDD ) вызываются когда мы обнаруживаем что нарушается какая-либо бизнес-логика. Безусловно, они тесно связанна с знаниями предметной области.

Они бросаются когда мы проверяем какое-либо утверждение, и видим что результат проверки не соответствует ожидаемому.

Например, есть метод добавления позиции в заказ:

В процессе добавления позиции происходит куча различных действий. И при этом периодически проверяются различные утверждения: что все суммы сходятся, что заказ может быть доставить — это и есть эксепшены утверждений.

Здесь можно подискутировать на тему необходимости подобных эксепшенов:
Например, можно написать тесты на методы перерасчета стоимости заказа, и проверка в теле метода — не более чем дублирование теста. Можно проверять возможность доставки заказа с новой позицией до добавления позиции (чтоб предупредить об этом пользователя, как минимум)

Но практика показывает, что далеко не всегда удается написать тесты для всех инвариантов объекта. И невозможно защититься от, например, нового разработчика, который может накодить все что угодно.

Поэтому в критичных местах такие эксепшены нужны однозначно.

Изменение логики для избегания эксепшна

Как я уже говорил, PHP разработчики боятся эксепшенов. Они боятся их появления, и боятся бросать их самостоятельно.

И в этой борьбе с эксепшенами многие допускают ошибку: отступают от изначально четкой, понятной, прямолинейной логики в сторону каких-либо допущений, чтобы хоть как-то выполнить операцию.

Вот пример: необходимо просто отобразить страницу по id (чтоб вы понимали — это реальный код из известного проекта)

Несмотря на простейшую и понятную задачу — здесь совершенно дикая логика.
Мало того, что она может показать пользователю совершенно не то что надо, так она еще и маскирует наши баги:

Тоже из реального проекта, и мотивация такая-же: вернуть хоть что-то, но не вызывать эксепшн, несмотря на то, что метод явно должен возвращать код города, а не региона.

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

Мое мнение — это недопустимо. Просто когда ты работаешь с большими деньгами (а я с ними работал довольно долго), вырабатывается определенные правила, и одно из них — прерывать операцию в случае любого подозрения на ошибку. Транзакция на 10 млн баксов: согласитесь, ее лучше отменить, чем перечислить деньги не тому человеку.

Конечно, обычно мы имеем дело с менее рискованными операциями. И в случае бага, например, инвалид не сможет оставить заявку на установку пандуса в подъезде. И разработчик на раслабоне (его ведь даже не оштрафуют) пренебрегает этими элементарными правилами, мол, подумаешь, мелочь какая. Проблема в том, что когда ему доверят что-то критически важное — вряд ли его подход измениться. Ибо проблема не в знаниях, и не в риске, а в дисциплине и в отношении к делу. И получается, что после таких программистов у нас где-то трубы зимой лопаются, где-то нефть разливается тоннами, где-то люди умирают десятками, где-то деньги воруются миллионами. Подумаешь, мелочь какая!

Собачки

Собачки вместо isset используют для лаконичности кода:

Действительно, выглядит намного короче, и на первый взгляд результат такой же. Но! опасно забывать что собачка — оператор игнорирования сообщений об ошибках. И @$policy->owner->address->locality вернет null не потому-что проверит существование цепочки объектов, а потому-что просто проигнорирует возникшую ошибку. А это совершенно разные вещи.

Проблем в том, что помимо игнорирования ошибки Trying to get property of non-object (которое и делает поведение собачки похожим на isset ), игнорируются все другие возможные ошибки.

PHP — это магический язык! При наличии всех этих магических методов ( __get, __set, __call, __callStatic, __invoke и пр.) мы не всегда можем сразу понять что происходит на самом деле.

Таким образом, столь необдуманное использование собачки потенциально создает огромное кол-во проблем.

Послесловие

Но попробуйте собрать конструктор без инструкции… Эта мысль похожа на бред. Тем не менее, программисты без всех этих знаний прекрасно работают. Годами. И им это не кажется бредом — они даже не понимают, что что-то делают не так. Вместо этого они жалуются что им дали слишком мало времени.

И если в послесловии предыдущего поста я предлагал задуматься, надеясь что кто-то изменит свой код к лучшему, то теперь я потерял эту надежду. Видимо, люди действительно ценят только тот опыт, за который заплатили.

Так что всем, кто прочел этот пост и подумал “что за бред”, “я все это знаю, но применять лень”, или “будет сосунок мне указывать” — я желаю совершить баг. Баг, за который оштрафуют или уволят. И тогда вы, возможно, вспомните этот пост, и задумаетесь: “возможно я и в правду что-то делаю не так”?

Совершите его как можно скорее. Ибо лучше один раз ошибиться, но прозреть, чем всю жизнь прожить быдлокоддером. Аминь.

Источник