- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
using System;
namespace Test
{
public class HttpException : Exception
{
public HttpException(int status)
{
StatusCode = status;
}
public int StatusCode { get; set; }
}
class Program
{
static void TestCatch(int status)
{
try
{
throw new HttpException(status);
}
catch (HttpException ex) when (ex.StatusCode == 404)
{
Console.WriteLine("Not Found!");
}
catch (HttpException ex) when (ex.StatusCode >= 500 && ex.StatusCode < 600)
{
Console.WriteLine("Server Error");
}
catch (HttpException ex)
{
Console.WriteLine("HTTP Error {0}", ex.StatusCode);
}
}
static void Main(string[] args)
{
TestCatch(404);
TestCatch(501);
TestCatch(101);
}
}
}
Follow us!
- оператор ветвления
- оператор цикла (желателен опыт работы с коллекциями)
- оператор возврата
- оператор обработки исключений
А в жабе есть матч по ИЛИ catch (HttpException|AnotherException ex).
Вот бы скрестить жабу с# гадюкой.
https://ideone.com/yaYl9Y
А ваш язык так что, не умеет?
Обработай ещё этих ебучих JSONException'ов да выпей джавы.
Ну что за жабья философия... Программист - это ребёнок, которого надо водить за ручку и заставлять есть кашу?
Есть куча вполне разумных кейсов, когда исключения достаточно "обработать" в одной точке - цикле обработки сообщений, main'е и т.п. И я не хочу обмазывать все функции этими throws Exception, только чтобы дотащить этот сраный JSONException до этой точки. Даже в крестах это уже осознали и выкинули все спецификации исключений помимо "не кидает ничего" и "что-то может кинуть".
Всё. Если программист хочет сделать что-то полезное для юзера при каких-то конкретных исключениях - он прочитает о них в документации и обработает (какие-нибудь FileNotFound или NetworkIsDown, к примеру).
Остальные исключения обрабатывать нет никакого смысла - либо catch all + log либо terminate.
> компилятор вам не поможет
Он уже помог разделить код на успешный путь (вернули результат) и неуспешный путь (вернули исключение). И даже прокинул неуспешный путь через весь коллстек, в отличие от той же сишки где каждый вызов надо обмазывать проверками. И даже дал возможность прикрепить какую-то полезную инфу и строчку для лога. Что ещё надо то?
> что должна делать программа если NetworkIsDown
А я ебу? Это конкретная программа решает. Выйти с ошибкой, попросить юзера подключить сеть если мы на мобиле, отложить в очередь до появления сети и т.п.
Важен факт ошибки, и конпелятор не даёт его проебать.
Важны простые и популярные ошибки, которые юзер реально может исправить. А они, внезапно, обычно находятся в самом первом исключении - "нет доступа", "файл не найден", "неожиданный символ {". И чем меньше ты заворачиваешь эти исключения, тем легче их выловить на верхнем уровне и показать на понятном для юзера языке, возможно даже с локализацией.
А для автономных сервисов выбор между логами и обмазыванием трайкетчами вообще очевиден.
> тупо передать ошибку наверх
Именно так. Если сразу с ошибкой ничего придумать не удалось - значит пусть с ней разбирается generic обработчик аля Залогировать и Сдохнуть™. В середине цепочки вызовов она нахуй никому не нужна.
> We went to lunch afterward, and I remarked to Dennis that easily half the code I was writing in Multics was error recovery code. He said, "We left all that stuff out. If there's an error, we have this routine called panic(), and when it is called, the machine crashes, and you holler down the hall, 'Hey, reboot it.'"
А то пишут, пишут... исключения, трайкетчи какие-то... Голова пухнет. Взять всё, да и завершить...
Во-вторых - это же просто сахар для try-с-перевбросом.
Лучше уж возвращать Either с паттерн-матчингом в тех случаях, где это реально надо. И да, IoException и JsonException - это не те случаи, где это реально надо.
Хочешь ли ты показывать юзеру на какой строке сломан жсон в твоём описании пакета обновлений или ответе от сервера. Да нет конечно, он все равно ничего не сможет с этим сделать. Записать по catch-all в лог да и всё.
А JsonException примечателен тем, что полезный кейс у него ровно один. В момент парсинга. Во всех остальных местах, откуда его кидают, это просто ошибка программиста, которая не должна быть checked. В этом и вред cheched исключений.
Вот именно :)
Если я поставил try - значит мне интересно это исключение. Если не поставил - значит нет.
И тут мы приходим к выводу, что спецификации исключений не нужны.
Ну это ж не сишка - солнце не потухнет, луна не наебнётся. Ну задаст тебе юзер вопрос о "неизвестной ошибке", ну разберёшь её по логу и добавишь обработчик.
Х.з., имхо фича, которая заставляет писать и поддерживать бойлерплейт, должна приносить в замен очень много пользы. Иначе она тупо вредна и её не надо включать в язык.
Но ты слишком высоко замахнулся.
Checked exceptions - это мелкая фича на уровне "а давайте выкинем из крестов auto и и будем писать все типы явно, вдруг функция вернёт не тот тип, что мы ожидали". В общем-то порядок пользы и бойлерплейта совпадает.
Да, по документации. Как и кучу других констрейнтов на аргументы, результаты и сайд-эффекты которые большинство систем типов не позволяют описать.
/thread
Пойду в дум ебашить.
ИМХО, такой подход не исправляет Фатальный Недостаток checked-исключений: если вдруг вызываемый метод отрефакторится и начнёт кидать ещё одно исключение, тебе придётся лазить по всем цепочкам вызовов и править все методы из цепочек. Это, мягко говоря, неудобно.
Вот есть метод A, который кидает TyHujException, есть метод B, который вызывает метод B:
Тогда при checked-исключениях программист обязан либо поймать TyHujException на моменте вызова A(), либо не ловить, но добавить к сигнатуре B() «throws TyHujException». А как предлагаешь ты?
Я рассматриваю не два уровня, а три. getPetuh() сообщает об ошибке InternalPetuhError посредством throws, getKuryatnik() вызывает getPetuh() и игнорирует InternalPetuhError (не засирая им свою сигнатуру), doWork() вызывает getKuryatnik() и не может понять, откуда ему прилетело InternalPetuhError.
Весь смысл check-исключений можно свести к двум утверждениям:
1) Для любого вызова гарантируется, что он не приведёт к аварийному завершению работы программы;
2) Для любого вызова гарантируется, что программист рассмотрел все возможные ошибки и решил, что с ними делать.
Таким образом, сочетание двух этих гарантий позволяет создавать максимально надёжный код: любая возможная ошибка в конце концов будет где-то обработана программистом. При этом благодаря второму утверждению программисту удобнее обработать ошибку как можно раньше.
А с возможностью проигнорировать какие-то исключения получается, что обе этих гарантии перестают работать: любой вызов может выкинуть какую-то левую фигню, не указанную в throws.
Конечно, почему нет?
> Не все ошибки. Например, ошибку OutOfMemory программист не рассматривает. И NPE Тоже.
А не надо решать за программиста, что ему нужно рассматривать, а что не нужно. Программа вполне может при получении OOM попытаться, например, снизить разрешение текстур.
> Любая функция может их выкинуть.
А какой вообще тогда смысл в checked исключениях? Зачем писать весь этот бойлерплейт, если получившаяся программа ничем не отличается от таковой без бойлерплейта? Что первая, что вторая могут рандомно упасть из-за рандомной необработанной ошибки. Информацию о типах выбрасываемых исключений спокойно можно найти в доке (если это нормальная дока, а не говно) либо вообще заставить это делать конпелятор.
Когда нужно — я и векторные исключения ставлю, чтобы «сегфолты» ловить.
Да, я понял, что «одноуровневые» исключения хорошо ложатся на такую систему. Однако уже для двухуровневых (A() вызывает B(), который вызывает C(), который кидает исключение) её смысл по большей части исчезает, и она становится простым бойлерплейтом.
В этом случае нет абсолютно никакой разницы: что есть checked исключения, что их нет. А бойлерплейт есть.
И ты никак, без чтения сорцов, не узнаешь, что автор какой-то говнолибы решил проигнорить какое-нибудь ConnectionTimeout.
Беда checked исключений с ignore() в том, что они заставляют писать столько же бойлерплейта, что и checked исключения без ignore(), но при этом обеспечивают гораздо меньше безопасности.
ДОБРОЕ ИМЯ ДОБРАЯ СЛАВА В ЧЕСТИ 1024--, тебе тоже.
В языках с исключениями, в отличие от сишки, нельзя забыть обработать ошибку - необработанное исключение не триггерит UB. Поэтому пользы от checked exceptions, имхо, меньше чем вреда.
Если компилятор вычислит это, сам, будет очень хорошо.
Я не хочу читать весь список ошибок, а потом ещё сверять его с ошибками, которые могут добавлять внешними питухами.
Например, если мы передаём в фукнцию другую функцию или объект, то при вызове этой функции или метода объекта может вылезти исключение, которое функция не бросает. И набор исключений зависит не от того, что написал автор, а от того, что написали автор с пользователем, а также от питушни вроде кодовставок внутри #ifdef.
выше ветку не читал, но
https://ideone.com/CcDVzm
Вот сейчас обидно было. В приведенном выше примере сообщение не залогировалось, потому что никакого сообщения в исключении нет. В консоль вываливается содержимое проперти «Message», ToString() тут вообще никаким боком. Кастомное исключение можно сделать примерно так:
Вывод в сосноль:
всё верно, держи плюск
Исключения либо ещё слишком мало понятны народу (как табы), либо могут использоваться только в очень хорошо спроектированном коде, и не каждый проект может быть того масштаба, когда исключения действительно помогают, а не запутывают.
Это же банальное нарушение структурного и процедурного программирований, нарушение инкапсуляции. Внутренняя питушня может легальным образом произвольно повлиять на все слои абстракции над ней. Какое-то говно.
А потом приходят полуборманды и говорят, что не будут ловить исключения, пусть пользователи их библиотек разгребают то, что было кинуто питушнями, которые использовали использованные полубормандами библиотеки.
А потом приходят борманды и говорят, что не будут ловить эту питушню и попросят уже конечного пользователя сообщить о проблеме 0xCCD3208EF Invalid call.
То ли дело сишка, где имеем либо кривое говно, либо корректный код, который не может вернуть что-то, что не указано в документации или в определении функции.
А в языках с исключениями кривое говно называют библиотеками.
Что с исключениями что без них код работает совершенно одинаково. Просто в варианте с исключениями не надо обмазывать каждый вызов бойлерплейтом. И можно приложить чуть больше инфы, чем просто инт.
А вот исключения постоянно забывают проверить, поэтому наружу лезет какая-то питушня из кишок библиотек. И это считается нормальным.
Вариант с монадами отличный. Там и пердолиться руками надо много меньше, и забыть проверить невозможно. Ты точно знаешь, что возвращает функция, нет никакого протыкания инкапсуляции.
Более того, если завтра авторы библиотеки A поменяют библиотеку B на библиотеку C — всем клиентам придётся менять catch (B_Exception) на catch (C_Exception) — при том, что публичный интерфейс библиотеки A не меняется никак, меняются детали реализации. И это пиздец.
UPD: я, как клиент библиотеки A, вообще не должен знать об особенностях её реализации (в частности, какие она там использует библиотеки) ничего. А пробрасываемые исключения этот принцип успешно похеривают.
О_о ну вообще-то публичный интерфейс поменялся. То, что этого тебе не скажет компилятор, говорит просто о том, что компиляторам стоит в этом плане ещё есть куда расти. А так - документация, которая, на мой взгляд, тоже является частью публичного интерфейса.
> я, как клиент библиотеки A, вообще не должен знать об особенностях её реализации
- это очень смелое заявление.
> это очень смелое заявление.
И совершенно верное. Или я что-то пропустил, и банальная инкапсуляция вышла из моды?
Авторы нормальных либ, кстати, эту проблему прекрасно понимают, и исключения из своих кишок не пробрасывают:
Но сама возможность такого — говно.
- у тебя другие исключения могут прилетать. Повторюсь: дока, где это должно быть описано, это тоже часть публичного интерфейса.
> Или я что-то пропустил, и банальная инкапсуляция вышла из моды?
- это уже не инкапсуляция, это уже изоляция какая-то. Допустим, по поводу обычных типов и методов я с тобой соглашусь. Но исключения они на то и исключения, что они демонстрируют исключительную ситуацию. Зачем мне затенять то место, откуда стрельнуло что-то исключительное?
> Авторы нормальных либ
> нормальных
- пошла вкусовщина.
Значит, в публичный интерфейс пролезли детали реализации. Это тоже эталонное говно.
> это уже не инкапсуляция, это уже изоляция какая-то
Нет, это в точности инкапсуляция. Сокрытие деталей реализации, алло, это пишут в любой книжке «ООП за 20 минут»!
> Зачем мне затенять то место, откуда стрельнуло что-то исключительное?
Затем, что это место никак не касается клиентов библиотеки. Если из метода A::F() мне прилетело исключение — это значит, что в исключительную ситуацию попал метод A::F(). Именно A::F(), метод из библиотеки A!
> пошла вкусовщина
Это не вкусовщина, это реальный пример правильно сделанных исключений.
- значит, почти любая документация состоит на 90% из эталонного говна (по мнению gost'а).
> это место никак не касается клиентов библиотеки.
- откуда ты знаешь, касается оно или нет? Ты в курсе тонкостей всех охулиардов проектов на матушке Земле? Ну камон, не будь таким Нарциссом
> на 90%
[citation needed]
> откуда ты знаешь, касается оно или нет?
Оттуда, что это самые основы ООП. Оттуда же, откуда знаю, что нельзя дёргать приватные члены чужих классов.
> Ты в курсе тонкостей всех охулиардов проектов на матушке Земле?
Мне не нужно быть в курсе тонкостей всех охулиардов проектов, чтобы понимать, что раскрытие деталей реализации — это говно. В любом случае говно.
https://en.cppreference.com/w/cpp/algorithm/sort
деталь реализации? Деталь.
заходишь, а там
Чо, не деталь реализации?
> Оттуда же, откуда знаю, что нельзя дёргать приватные члены чужих классов.
- а чего ты вдруг заговорил про приватные члены, если типы исключений у нас публичные?
> раскрытие деталей реализации — это говно
- даже если это не противоречит здравому смыслу, но противоречит книжке "ООП за двадцать минут"?
Вовсе нет. Это описание публичного интерфейса элементов, который ожидает эта функция. С тем же успехом деталью реализации можно назвать типы входных параметров.
> Чо, не деталь реализации?
И опять нет. Здесь описывается наблюдаемое поведение политик.
Впрочем, ладно: детали реализации действительно могут быть добавлены в документацию. Однако это должны быть просто справочные материалы, на которые никак нельзя опираться при разработке программы-клиента. Например, как здесь: https://en.cppreference.com/w/cpp/algorithm/for_each (раздел «Possible implementation»).
> а чего ты вдруг заговорил про приватные классы, если типы исключений у нас публичные?
Потому что приватные члены класса — это детали его реализации, и используемые внутренние библиотеки — тоже детали реализации библиотеки.
> даже если это не противоречит здравому смыслу
Это противоречит здравому смыслу. Чем больше деталей реализации раскрывается клиентам библиотеки (причём раскрывается так, что клиенты становятся зависимы от них) — тем труднее становится детали реализации поменять. А простота смены внутренней реализации — это самое главное преимущество, которое обеспечивает инкапсуляция.
- это ты сам придумал, в доке такого нет. Там написано, что сравнение происходит при помощи такого-то оператора и гуляйте.
> наблюдаемое поведение
- поведение это не реализация?
Библиотека может оборачивать исключения, а может не оборачивать. Вызывающий код может лучше знать, что ему делать с исключением конкретного типа из конкретной библиотеки, потому что мы живём в неидеальном мире хаков, костылей и всяких трюков, а ты его такой возможности своими обёртками лишаешь. Противоречит здравому смыслу слепое следование мантрам.
А безболезненная смена внутренней реализации, при которой мы кишки поменяли и никто не заметил, бывает только на проектах на 10 файлов.
В мире «C++» это и есть описание публичного интерфейса, потому что перегруженные операторы — это его часть.
> поведение это не реализация?
Поведение — это не реализация.
> Библиотека может оборачивать исключения
Хорошая библиотека.
> а может не оборачивать
Говно.
> Вызывающий код может лучше знать, что ему делать с исключением конкретного типа из конкретной библиотеки
И таким образом он намертво себя прикручивает к деталям реализации библиотеки.
> мы живём в неидеальном мире хаков, костылей и всяких трюков
Да. Хаки, костыли и «всякие трюки» — это говно. Говно, от которого надо избавляться и которое уж точно не надо плодить. В точности следуя твоей логике, все члены любых классов должны быть публичными — ведь мы же живём в неидеальном мире хаков, костылей и всяких трюков, и своей приватностью их все ломаем!
Проводя аналогии, мы живём в неидеальном мире фастфуда, колы и всяких чипсов. Означает ли это, что здоровое питание нинужно?
> А безболезненная смена внутренней реализации, при которой мы кишки поменяли и никто не заметил, бывает только на проектах на 10 файлов.
Нет. Если внутренняя реализация не пролазит в публичный интерфейс — её можно спокойно менять. В таком случае, даже если какой-то говнокодер завязал на неё свой код — это будут исключительно его проблемы, у нормальных людей всё будет работать.
- а что тогда?
> И таким образом он намертво себя прикручивает к деталям реализации библиотеки.
- ну и хер с ним. Мне сидеть дрожать 10 лет над тем, что у моих зависимостей сменятся зависимости, или иметь ништяки уже сегодня?
Ну и так-то конечный код всё равно придётся перекомпилировать, если речь про кресты etc.
Культ карго какой-то.
> Проводя аналогии
- не надо, пожалуйста, проводить аналогии, потому что обычно, как и в этом случае, они хуёвы и абсолютно неуместны. Здоровое питание это такая же маркетинговая хуета, как и оопэшные мантры про повсеместную инкапсуляцию.
> все члены любых классов должны быть публичными
- да, потому что инкапсуляция должна быть на уровне модулей, а не типов, но это отдельный разговор.
> Нет.
- хватит троллировать. Ладно бы ты был каким-то рандомным неосилятором, а серьёзному кабальеро писать такую ересь должно быть стыдно.
- ну хотя тут я немного напиздел для случаев динамической линковки.
Поведение.
> ну и хер с ним. Мне сидеть дрожать 10 лет над тем, что у моих зависимостей сменятся зависимости, или иметь ништяки уже сегодня?
То есть ты за написание неподдерживаемого говнокода, главное — шоб побыстрее? Ну ок, предлагаю тебе переехать на «PHP» и писать перед каждым методом собачку.
> Ну и так-то конечный код всё равно придётся перекомпилировать, если речь про кресты etc.
Зачем? Зачем? В случае крестов придумали «pimpl».
> не надо, пожалуйста, проводить аналогии, потому что обычно, как и в этом случае, они хуёвы и абсолютно неуместны
Нет, это абсолютно точная аналогия.
> Здоровое питание это такая же маркетинговая хуета
Что, прости?! То есть все вот эти вот биологи с диетологами, которые занимаются темой здорового питания — маркетинговая хуета? И рекомендации ВОЗ — тоже? И даже, например, https://thl.fi/documents/189940/1496849/north_karelia_project.pdf/bb7ba7aa-1dc2-4319-90b9-d2c3ddc10d5e?
> да
А, ну понятно. Тогда тебе точно стоит перейти на «PHP».
> хватит троллировать
По-моему, троллирую тут не я, а человек, называющий инкапсуляцию культом карго.
Да, диетологи это по большей части хуета (но не все, разумеется). ВОЗ шаражкина контора про отмывание бабла в глобальных масштабах. Инкапсуляция без повода это культ карго. PHP - говно, сам на него переходи :)
> А, ну понятно.
- нет, не понятно, потому что комментарии лучше читать целиком. На этом откланиваюсь, потому что разговор потерял последние остатки конструктива.
Да.
> оно и есть реализация
Нет. Наблюдаемое поведение зависит от реализации, но не является ею. Точно так же, как результат выполнения функции зависит от её реализации, но не является ею.
> Да, диетологи это по большей части хуета (но не все, разумеется). ВОЗ шаражкина контора про отмывание бабла в глобальных масштабах.
Ну то есть ты считаешь, что рацион человека никак не сказывается на его, человека, здоровье?
> Инкапсуляция без повода это культ карго.
Не бывает «повода» для инкапсуляции. Бывают детали реализации, их надо скрывать — всё. Детали реализации, просачивающиеся в публичный интерфейс — априори говно, такого надо избегать.
Ну да, разумеется, в нашем неидеальном мире не всегда получается делать всё так, как надо. Однако это совсем не означает, что к этому не надо стремиться. Если есть выбор между говном и не говном — нужно выбирать не говно. Нет выбора — увы, придётся писать говно. Только говно от этого не станет нормой.
Допустим, все наши познания - предрассудки. Но тогда нужен хотя бы хороший пример того, как написали успешную программу без инкапсуляции, которая пережила все правки, и вообще поддерживается без проблем.
Я (говнокодер-с) только недавно правил питушню, которая была более-менее инкапсулирована, но всё равно вылезла в 3 дополнительных места. Только попердолился больше с кодом, никаких плюсов от недостатка инкапсуляции не получил.
> Ну то есть ты считаешь, что рацион человека никак не сказывается на его, человека, здоровье?
Кстати, может быть два варианта сразу.
1. Бабло массово отмывается на питушне, которая на 0.0001% полезнее обычного питухания.
2. Если кто-то жрёт радий или регулярно пьёт колу, умирает от неправильного питания.
- я тебе так отвечу: Стив Джобс был лучший диетолог ЕВПОЧЯ
Но вообще это который всем рассказал, какой телефон им нужен и как правильно его держать.
— ссылку на подробное описание этого проекта я кидал выше.
Но в общем-то да, никто не может сказать тебе, какое питание тебе нужно. Зато вполне успешно могут сказать, что если (условный) ты будешь регулярно кушать жареное мясо на ночь, то в итоге получишь определённые… осложнения.
f(x) = 2*x
f(x) = x+x
f(2) == 4 - это поведение? Если да, то поведение одно, а реализации две, поведение отходит к интерфейсу, реализация забивается в угол.
- это вореции.
Поведение у двух функций разное, разумеется. Иначе тебе придётся доказывать, что сложение и умножение это одно и то же.
В идеале, надо делать так, чтобы было правильно. В реальности — правильно настолько, чтобы уложиться в сроки.
Инкапсуляцию, SOLID и вот эти вот все «баззворды» придумали не просто так. Их проектировали умные люди специально для того, чтобы менее умные люди (или просто те, кому лень тратить время на переизобретение одного и того же) могли писать корректный, расширяемый и поддерживаемый код. Увы, но попытки забить на всё и говнокодить как придётся, «шоб работало», приводят только к созданию неподдерживаемого говнокода.
Другое дело - конкретная реализация в языке, где держат обратную совместимость, вставляют фичи средним арифметическим разумом комитета.
И не надо во всём обвинять бедного Госта. Инкапсуляцию придумали совсем другие люди — я тогда ещё не родился.
А остальной снобизм свой оставь пожалуйста для учеников на уроке информатики или первокурсников, которым ты возможно втираешь эту дичь.
По-моему, это достаточно очевидная цепочка.
Ты правда считаешь, что перечисленные мной god-object'ы и магические константы — это ОК, тесты писать не нужно, а кто утверждает обратное — тот сноб?
И потом ты собираешься это поддерживать, правда?
> Ты правда считаешь, что перечисленные мной god-object'ы и магические константы — это ОК, тесты писать не нужно, а кто утверждает обратное — тот сноб?
- нет, я так не считаю. God object это плохо, магические константы это тоже плохо, тесты писать конечно нужно, но тут уж как получается. Объясни только, пожалуйста, какое отношение это имеет к инкапсуляции? Она от констант и богообъектов вроде никак не спасает.
Их не надо «пробрасывать». Их надо обрабатывать согласно логике моего кода. Потому что если в моём методе появилось исключение, то это значит, что какая-то часть моего метода работает неправильно, и сообщить клиенту нужно именно об этом — соответствующим исключением, со всеми нужными метаданными.
> А что, если у тебя глубина дерева зависимостей больше единицы? Ты построишь целый фреймворк, который будет обёртывать исключения?
Нет, я буду обрабатывать исключительные ситуации в моём коде. В этом и состоит сила инкапсуляции: мне совершенно безразлично, какая там у используемой мной библиотеки глубина зависимостей. Я обращаюсь к библиотеке за каким-то результатом — и абсолютно не важно, как она его считает и какие либы вызывает. С исключительными ситуациями должна быть та же картина: я обращаюсь к библиотеке и ожидаю, что именно она мне скажет, что у неё произошла ошибка. А произошедшую ошибку я обработаю и выдам своему клиенту уже свою ошибку, которая будет описывать исключительную ситуацию в моём коде.
Да, это идеальная картина. В реальности же авторы либ* зачастую нарушают инкапсуляцию, в результате чего их клиентам приходится городить хаки и костыли, пихая в код совершенно ненужную для решения задачи информацию.
*И я тоже не безгрешен, разумеется, и тоже пишу говнокод. Увы, идеала не бывает — но это не значит, что к нему не надо стремиться.
> Объясни только, пожалуйста, какое отношение это имеет к инкапсуляции?
God-object'ы, магические константы, нарушения инкапсуляции — это сущности одного порядка, антипаттерны.
- почему это неправильно работает часть твоего метода? Эксепшн-то кинул не он. Ну, то есть, наверное, в условном идеальном ФП без побочек виноват будет твой метод, но обычно стрелять может откуда угодно и кто угодно.
Я правильно понимаю, что ты рассматриваешь любую исключительную ситуацию как исключительную ситуацию в твоём коде? Ну, это тоже подход, наверное.
> мне совершенно безразлично, какая там у используемой мной библиотеки глубина зависимостей.
- вопрос был скорее про случай, когда ты сам и есть автор этих зависимостей. То есть, когда из цепочки A <- B <- C <- D ты автор A, B и C.
Потому что если мой метод получил исключение и не может продолжать нормальную работу, то это значит, что он оказался в исключительной ситуации и должен сообщить о ней клиенту. К ФП и чистоте такой подход малость отношение имеет: его практиковали ещё наши деды, которые в «C» код возврата проверяли.
> вопрос был скорее про случай, когда ты сам и есть автор этих зависимостей. То есть, когда из цепочки A <- B <- C <- D ты автор A, B и C.
Тут, в принципе, не особо важно, кто автор этих библиотек. Если я соблюдаю принцип DRY, то каждая библиотека из этой цепочке делает разные вещи. Соответственно, и исключения у них тоже будут разными. С другой стороны, если библиотеки A, B и С — это части единого целого, какой-то более общей библиотеки, и их использование по отдельности не предполагается, то, думаю, вполне разумно будет ввести для них какой-либо общий набор исключений. Впрочем, такое решение само по себе пованивает, так что it depends.
- тогда всё же прошу пояснить мне по поводу friend class и пистона, а то вот непонятно, как умные дядьки и так обосрались.
- так если она произошла не у неё?
Один из важнейших принципов, который приходит с опытом: не делать больше работы, чем требуется.
Если тебе сейчас не нужен 100% loose coupling, то и не нужно сидеть и задрачивать его, у бизнеса есть требования, да и технический долг растёт не только в этом месте.
YAGNI — хороший принцип, и тоже придуман умными людьми. А вот применение этого принципа на практике, увы, хромает, поскольку точного определения «лишней функциональности» нет и вряд ли появится. В результате, при чрезмерно усердном его применении мы можем придти к отказу от, например, форматирования кода или грамотного именования переменных — ведь это же лишняя работа, программа прекрасно работает, даже если в ней названия всех переменных состоят из одной буквы!
Сравни, например, вот эти два исходника (оба всплывали на ГК, кстати): https://github.com/vk-com/kphp-kdb/blob/master/bayes/bayes-data.c и https://github.com/openbsd/src/blob/master/sys/netinet/ipsec_input.c. Как думаешь, который из них был написан людьми, не считавшими нужным стараться делать правильно, как пишут в умных книжках? И в который из них будет легче вносить изменения, когда понадобится рисовать не синию линию в виде кота, а оранжевый овал в виде кролика?
Если кодом пользуешься только ты, то можешь его и не форматировать и переменные называть huiPizda. И что, мало такого кода? Сам же знаешь, что есть такое понятие, как write-and-throw скрипты.
> Сравни, например, вот эти два исходника
- второй выглядит попричёсаннее, но я не настолько хорошо понимаю здоровые портянки на си, а потому на вопрос, какой из исходников я бы раскурил быстрее, ответить не могу.
Да, разумеется, код, который кроме тебя никто не увидит, можно писать вообще как угодно, и сам я тоже такое делаю. Главное в этом — чтобы такой код внезапно не начал на постоянной основе решать задачи бизнеса.
Да, причёсан, оформлен, декомпозирован и снабжён подробными комментариями (хотя казалось бы — вот где абсолютно бессмысленная работа, никак не помогающая задачам бизнеса!). И благодаря этому даже человек, не знакомый с портянками, сможет достаточно быстро понять, о чём там идёт речь (конечно, если ему это будет нужно, я ни к чему не призываю :-). А вот первый код, который писался олимпиадниками в их фирменном говностиле, понять и, главное, простить изменить смогут только его авторы (и то только в первые пару недель/месяцев). И тому несчастному, которого посадят разгребать эти конюшни, останется только дунуть, плюнуть и переписать всё с нуля. И это печально.
Интересные вопли, но лабу не приму. Приходите на пересдачу.
Вот реально вся эта питушня про маркетинговое здоровое питание инкапсуляцией и питушню уровня "работает - значит сделано" напоминает бугурт школьника, которого пытаются обучить чему-то, а он думает, что печальный многолетний опыт и просьбы не кормить орланов с рук, чтобы предотвратить новые случаи - лишь брюзжание стариков.
Я просто трачу больше времени на лишнее обсасывание своего кода, когда надо что-то изменить. Если там недостаток инкапсуляции, код разлагается и превращается в растекающуюся кашицу. Потом её нужно долго соскребать в баночки и тратить на это время вместо того, чтобы сделать что-то полезное.
Как это потом оформляется на performance review?
- сепульки и вореции.
Функции, процедуры, методы, операторы - это операции над своими аргументами. В ООП операции и первые аргументы слили вместе, сделав набор операций интерфейсом значений типа первых аргументов.
? :-)
Или, в идеале,
Или вообще как в «Go»:
- и как ты метаинформацию об ошибке будешь возвращать, если она тебе нужна?
Можно, реальный пример я привёл перед примером с «Go». Да, синтаксис отличается, но суть — одна и та же.
> - и как ты метаинформацию об ошибке будешь возвращать, если она тебе нужна?
Как деды ещё до нашего рождения возвращали: http://man7.org/linux/man-pages/man3/errno.3.html. Да, это «подход C».
> Как деды ещё до нашего рождения возвращали
- а где здесь метаинформация?
Вот есть у тебя функция
И есть , которая в цикле обрабатывает пачку value при помощи innerFunction и которая должна, когда innerFunction возвращает что-то не то, вернуть код возврата с метаинформацией про объект, на котором всё сломалось (представим, что это, например, имя файла). И куда мне эту метаинформацию записать?
Мелкие детали. Разве что с компайл-тайм проверками — да, беда. Но, повторюсь, сама суть подхода — явный возврат ошибки — абсолютно одинакова.
> И куда мне эту метаинформацию записать?
Куда хочешь. Можешь в отдельный выходной параметр, можешь вообще в какую-нибудь глобальную переменную.
EINVAL хватит всем.
- https://govnokod.ru/26533#comment536727
Профессор, я смущён. Зачем вы проваливаете тест Тьюринга?))) Ладно, мир дружба жвачка респиратор.
А здесь int — это не возвращаемое значение функции, а номер ошибки? Тогда да, всё правильно.
https://docs.microsoft.com/en-us/cpp/c-runtime-library/errno-constants?view=vs-2019
найди тут слово thread
Де-факто, кстати, на винде оно (разумеется) thread-local, а вот де-юре им быть не обязано.
И это жопа. Из-за этого rand() превратился в неюзабельную хуйню - где-то его стейт тред-локал, а где-то - тормозная глобалка под лочкой.