Здравствуйте, enji, Вы писали:

M>>Запретить null как класс. Вместо него использовать либо Option, либо вообще ничего не использовать.

E>И кстати — как его запретить? Вообще запретить простые ссылки? Т.е. везде только Option?

E>И во что тогда превратится такое: obj1.calc().doIt().getSome() ?

Ни во что не превратится, т.к. подавляющее большинтво этих obj — not null.

А где nullable, там превратится в явные разыменования: obj1.get.calc().get.doIt().getSome(). При условии, что программист понимает, что он делает, и уверен, что все эти объекты в данный момент действительно существуют. Хотя в моём коде таких многоэтажных конструкций нет; есть одиночные разыменования obj_?.get после сложных проверок прямо строчкой выше, где я в т.ч. убеждаюсь, что obj_? не пуст; а чаще встречается obj_?.getOrElse(throw new Exception("понятное сообщение об ошибке")).

Здравствуйте, dimgel, Вы писали:

D>Пожалуйста: doSmth(userOption.get). Здесь get может вылетить NoSuchElementException.

ну ок, и в чем разница с user.doSmth()? Или здесь doSmth — это именно внешний метод, и надо гарантировать непопадание туда null?

т.е. зачем нам доп сущность Option[User]?

Здравствуйте, dimgel, Вы писали:

D>есть одиночные разыменования obj_?.get после сложных проверок прямо строчкой выше, где я в т.ч. убеждаюсь, что obj_? не пуст; а чаще встречается obj_?.getOrElse(throw new Exception("понятное сообщение об ошибке")).

А в скале появился "?." ? Когда я пару лет назад на нее смотрел, в ней такого не было...

Здравствуйте, enji, Вы писали:

E>Здравствуйте, dimgel, Вы писали:

D>>есть одиночные разыменования obj_?.get после сложных проверок прямо строчкой выше, где я в т.ч. убеждаюсь, что obj_? не пуст; а чаще встречается obj_?.getOrElse(throw new Exception("понятное сообщение об ошибке")).

E>А в скале появился "?." ? Когда я пару лет назад на нее смотрел, в ней такого не было...

obj_? это просто я так идентификатор назвал.

Здравствуйте, enji, Вы писали:

D>>Пожалуйста: doSmth(userOption.get). Здесь get может вылетить NoSuchElementException.

E>ну ок, и в чем разница с user.doSmth()? Или здесь doSmth — это именно внешний метод, и надо гарантировать непопадание туда null?

doSmth — внешний метод. Будь он методом User, тогда надо было бы писать так: userOption.map(_.doSmth()).

UPD. Вернее, для безбожного разыменования по аналогии с doSmth(userOption.get), так: userOption.get.doSmth().

E>т.е. зачем нам доп сущность Option[User]?

Чтобы на уровне системы типов (т.е. на этапе компиляции) отличать nullable от not null и бить по рукам программиста, когда он пытается заюзать nullable как not null.

Здравствуйте, dimgel, Вы писали:

E>>т.е. зачем нам доп сущность Option[User]?

D>Чтобы на уровне системы типов (т.е. на этапе компиляции) отличать nullable от not null и бить по рукам программиста, когда он пытается заюзать nullable как not null.

так подожди. Обычная ссылка — это nullable. Option[T] — тоже nullable, просто имеет свои методы (упрощающие обработку null) и добавляет мусорок при вызове метода нижележащего объекта. А где not null?

Здравствуйте, enji, Вы писали:

E>так подожди. Обычная ссылка — это nullable. Option[T] — тоже nullable, просто имеет свои методы (упрощающие обработку null) и добавляет мусорок при вызове метода нижележащего объекта. А где not null?

Not null там, где ты решишь не использовать для nullable обычные ссылки, а только Option. Т.е., грубо говоря, пройдёшься по всему коду поиском "null" и отовсюду его вычистишь, заменив соответствующие типы T на Option[T].

Ну, кроме того, в скале есть маркер trait NotNull, из которого лично я все свои классы наследую, и ежели мне в бреду приспичит (хотя ни разу не случалось) передать null параметру отнаследованного от NotNull типа, компилятор ругнётся.

Здравствуйте, dimgel, мы писали:

D>Not null там, где ты решишь не использовать для nullable обычные ссылки, а только Option. Т.е., грубо говоря, пройдёшься по всему коду поиском "null" и отовсюду его вычистишь, заменив соответствующие типы T на Option[T].

D>Ну, кроме того, в скале есть маркер trait NotNull, из которого лично я все свои классы наследую, и ежели мне в бреду приспичит (хотя ни разу не случалось) передать null параметру отнаследованного от NotNull типа, компилятор ругнётся.

В котлине это красивше порешали (единственное, что мне там понравилось, правда уже забыл подробности — помню только, что там нету никаких Option / Maybe, и все ссылки по умолчанию not null), но увы. Где котлин, а где скала.

Здравствуйте, WolfHound, Вы писали:

S>>Всякие статейки в инетах читаем? Похвально, но посоветовл бы заглянуть в реальные
S>>исходники, и узреть как оно на самом деле там наворочено.
WH>Я реально измерял производительность.
WH>Коды возврата слили.
Это каким это образом пара проверок может слить?

Здравствуйте, WolfHound, Вы писали:

S>>"Правильно реализованные", это как? Смотрел как они реализованы в ELF+gcc/clang/solarisstudio.
WH>Вот так:
WH>

WH>The second scheme, and the one implemented in many production-quality C++ compilers, is a table-driven approach.

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

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, LaptevVV, Вы писали:

LVV>>Одна из серьезных проблем, которую практически не поминают — это парадигма обработки исключений.
LVV>>По сути это событийное программирование.
LVV>>И вот получается, что в одной проге смешаны как минимум две, а то и три парадигмы: ООП+событийное (и очень часто процедурное).
E>Да хоть 10 парадигм в одной проге — ничего страшного. Главное парадигмы применять правильно и тогда, когда это имеет смысл. А проблемы с исключениями возникают тогда, когда с их помощью начинают хреначить логику, и они становятся не исключениями, а нормальным потоком выполнения программы.
Вот именно! Правильно применять — это надо быть опытным и дисциплинированным.
Программисты хреначить начинают — именно потому, что <предоставляется возможность>.

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

Здравствуйте, Vain, Вы писали:

V>Здравствуйте, WolfHound, Вы писали:

S>>>"Правильно реализованные", это как? Смотрел как они реализованы в ELF+gcc/clang/solarisstudio.
WH>>Вот так:
WH>>

WH>>The second scheme, and the one implemented in many production-quality C++ compilers, is a table-driven approach.

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

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

Здравствуйте, uncommon, Вы писали:

V>>Это только в том случае будет быстрее если, к примеру, запрос по таблице работает быстрее запроса через код ветвлением, что к примеру, в risk платформах может быть с лёгкостью не так, так как там проц в разы быстрее памяти и быстрее результат ветвлением найти чем запросом по таблице.
U>Мне кажется, ты не понимаешь какой случай оптимизируется в table-driven реализации исключений. Это тот случай, когда никаких исключений не выбрасывается. Т.е. код для обработки исключений есть, но он никогда не вызывается. Поэтому поиск по таблицам делать вообще никогда не надо. И вся сложность переносится именно в эти таблицы, которые достаточно медленные, но это не важно, потому чтоо исключения должны происходить только в исключительных случаях, а в таких случаях нам на производительность наплевать.
непонятно только, как исключения в этом случае будут быстрее кодов ошибок?

Здравствуйте, Vain, Вы писали:

WH>>Коды возврата слили.
V>Это каким это образом пара проверок может слить?

Пара проверок vs никаких проверок — вот таким образом.

Здравствуйте, Vain, Вы писали:

V>непонятно только, как исключения в этом случае будут быстрее кодов ошибок?

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

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

Здравствуйте, uncommon, Вы писали:

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

Гладко было на бумаге, да забыли про овраги. В реальности при наличии исключений быдлокодят будь здоров. Ну может разве что в софте Curiosity все хорошо. Ускорение с исключениями — чистая теория. На практике в том же дотнете исключений в API хоть одним местом жуй.

Здравствуйте, uncommon, Вы писали:

WH>>>Коды возврата слили.
V>>Это каким это образом пара проверок может слить?
U>Пара проверок vs никаких проверок — вот таким образом.
ну так и с кодами возврата также — не вроверяют и нет проверок

Здравствуйте, uncommon, Вы писали:

V>>непонятно только, как исключения в этом случае будут быстрее кодов ошибок?
U>Коды ошибок всегда проверять нужно, произошла ошибка или нет. А исключения задействуются, только когда произошла ошибка.
Ну это не совсем так, при входе в try блок ведь чтото должно делаться, не так ли? Единственный вопрос, быстрее ли оно обычного условия в случае проверки кода возврата.

Здравствуйте, dimgel, Вы писали:

D>Да и нехай значит. Всё лучше, повторюсь, чем молча глотать. А на верхнем уровне можно журналировать всё непойманное, потихоньку фикся ранее забытое.

Тут проблема еще глубже. Корни этого вопроса растут из того, что в некоторых новых языках решили отказаться от искючений признав их бякой. Аргумент один "ИМХО".

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

Здравствуйте, vsb, Вы писали:

vsb>А что ещё может сделать нижний уровень? Ну да, он может сказать "Production database unavailable" вместо "Socket disconnected", но кому от этого станет лучше? Пользователю лучше не станет. Администратор/программист из стектрейса и так поймёт, что проблема в БД-коде.

У тебя может быть универсальная функция генерирующая исключение, например, string.Parse(). Далее может быть компонент читающий файл. Ну, и некий потребитель который может вывести сообщение пользователю. Логично, если компонент читающий файл поймает исключение и перезапакует его в свое, в котором говорится, что не шсмогла прочесть файл, так как возникла ошибка "...". Тогда конечный код выведет разумное сообщение об ошибке, мол "Не смогли прочитать файл, так как "№;%" не является числом".

vsb>По сути я вижу отличие исключений от кодов возврата только в одном use-case. Если мы хотим проглотить ошибку.

А тут вообще никакой связи нет, а тебе нужно учиться правильно формулировать вопросы.

Поглотить мы ее может всегда и везде.

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

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

vsb>Вот такое у нас приложение — работаем до последнего и плевать, что там на улице. Тогда с кодами возврата отработает больше кода. С исключениями — выполнение оборвётся сразу и исключение улетит далеко наверх. Ну или ставить try { ... } catch {} везде. Но это ведь в любом случае плохая практика и даже хорошо, что исключения её усложняют.

Это в корне не верное утверждение. Ставить try везде нет смысла. Кроме того в нормальных языках кроме catch есть еще и finally, который используется в разы чаще (не всегда явно, иногда через using или foreach).

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

Еще один случай — добавление информации в исключении (я его описал выше). Скажем есть слишком универсальная ошибка и мы перепаковываем ее в более конкретную добавляя информацию (например, о файле, как в примере выше).

А вот код возврата заставляют обрабатывать не только всегда и везде сами ошибки, но еще и портят основной код разбавляя его этой логикой. Кстати, самое название уже говорящее, не информация об ошибке, а какие-то не внятные коды. На практике это часто сводится к возврату чиселок. Кто работал с API VS знает, что порою понять по HResult-у, что же пошло не так практически невозможно.

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

В новых языках (в которых по факту мало нового) основная проблема не в иделогии исключений, а в принятых в них технических решениях. Так автоматический подсчет ссылок проблематично сделать вместе с исключениями, так как при раскрутке стеке (во время исключения) нужно отменить все увеличения ссылок, или объекты не умрут когда положено. У стековых деструкторов тоже не все ОК с исключениями. Вызвать то их можно, но раскрута стека, при этом, становится существенно дороже.