ARK> class Test
ARK> {
ARK> private MyItem[] _myArray;
ARK> protected abstract void ProcessInternal(MyItem item) throws Error; // видим возможность вылета и можем найти по Ctrl-F
ARK> public void Process() throws Error// видим возможность вылета и можем найти по Ctrl-F
ARK> {
ARK> foreach (var item in _myArray)
ARK> {
ARK> try!(ProcessInternal(item));// видим возможность вылета и можем найти по Ctrl-F
ARK> }
ARK> // здесь _myArray оказался в неизвестно каком состоянии
ARK> }
ARK>
Какой-то ад. Мало того, что надо писать тонны дополнительного кода, так эта зараза еще распространяется вверх по всей цепочке вызовов (хуже GPL, ей-богу).
В итоге, любой функции, даже написанной через три месяца другим человеком четырьмя уровнями выше, рпидется столкнуться с тем, что возвращается не нужное значение, а никому не нужная обертка Result<список любых типов любой сложности, внутренности или вложенности>?
s22>Где то читал, что "вменяемый GC" на телефоне требует как минимум 0,05 секунды задержки, что Apple признали не приемлемым, так как пользователь будет ощущать дискомфорт.
эээ чо? Сфероваккумный GC на сферовакуумном телефоне.
У Apple'а есть Objective-C, в который пытались впихнуть GC, и есть Swift, который должен быть совместимым со всем кодом, написанным на этом самом Objective-C. Вот тут да, возможно и есть задержка в 0.05 секунды банально из-за того, что нельзя натянуть GC на Objective-C.
В языке типа Erlang'а GC вообще незаметен для приложения, и на него не влияет. Но Erlang не особо впихуем на телефоны Хотя...
Здравствуйте, Mamut, Вы писали:
M>В итоге, любой функции, даже написанной через три месяца другим человеком четырьмя уровнями выше, рпидется столкнуться с тем, что возвращается не нужное значение, а никому не нужная обертка Result<список любых типов любой сложности, внутренности или вложенности>?
Ну так пусть функция возвращает нужное значение, в чем проблема? Ах, внутри файл читается? Тогда будьте добры отреагировать на потенциальный сбой.
Не хотите? Используйте другие языки, никто не против.
Лично мне нравится подход Rust/Swift.
M>Чем это хорошо? А ничем.
M>>В итоге, любой функции, даже написанной через три месяца другим человеком четырьмя уровнями выше, рпидется столкнуться с тем, что возвращается не нужное значение, а никому не нужная обертка Result<список любых типов любой сложности, внутренности или вложенности>?
ARK>Ну так пусть функция возвращает нужное значение, в чем проблема?
В том, что никто не знает, что это за «нужное значение».
ARK>Ах, внутри файл читается? Тогда будьте добры отреагировать на потенциальный сбой.
Каким образом, если исключений нет?
M>>Чем это хорошо? А ничем. ARK>Это хорошо тем, что все происходит _явно_ и видно в коде.
Да ничего там «явного». Будет две сотни try! и один общий Err("строка"). И иди разбирайся.
Здравствуйте, AlexRK, Вы писали:
ARK>А нужно ли оно? Отреагировать на панику ведь все равно никак нельзя. Поэтому просто можно считать, что ее нет.
Во первых, noexcept в плюсах предоставляет дополнительную информацию компилятору, а значит помогает оптимизациям. Во вторых, в минусы исключений записывается неявность — про панику точно так же из документации узнавать приходится. Ну и в третьих, "иногда" среагировать можно.
Здравствуйте, VladD2, Вы писали:
VD>"Не принято" — это зачет!
Понимаю, что это звучит забавно. Но ведь и в плюсах можно аборт изнутри либы звать, но так обычно всё-таки не делают.
VD>Дык, все ненавистники исключений обычно и имеют опыт их использования исключительно на С++. Возможно, если бы авторы того же Раста по пользовались бы языками где исключения реализованы качественно, у них и не возникло бы желания возвращаться в прошлые века и городить сахар над кодами возврата.
Ну у меня как раз, в основном, плюсовых опыт, а исключения в расте тоже хочется. Так что подозреваю, что причина в другом. Опять же, авторы ссылаются и на другие языки.
Здравствуйте, Mamut, Вы писали:
M>>>В итоге, любой функции, даже написанной через три месяца другим человеком четырьмя уровнями выше, рпидется столкнуться с тем, что возвращается не нужное значение, а никому не нужная обертка Result<список любых типов любой сложности, внутренности или вложенности>? ARK>>Ну так пусть функция возвращает нужное значение, в чем проблема? M>В том, что никто не знает, что это за «нужное значение».
Ничего не понял.
(Если что, говнокод, в том числе и "список любых типов любой сложности, внутренности или вложенности", можно написать на чем угодно.)
ARK>>Ах, внутри файл читается? Тогда будьте добры отреагировать на потенциальный сбой. M>Каким образом, если исключений нет?
Проверкой результата функции, представленного алгебраическим типом.
M>>>Чем это хорошо? А ничем. ARK>>Это хорошо тем, что все происходит _явно_ и видно в коде. M>Да ничего там «явного». Будет две сотни try! и один общий Err("строка"). И иди разбирайся.
Как я понимаю, авторы раста рассчитывают на то, что код будет писаться в основном таким образом, чтобы избегать исключений где попало. Поэтому — в теории — не должно быть try везде, где только можно.
Бич дотнета и явы, NRE, они устранили, это уже неплохо. Если бы еще были правильно сделанные предусловия, тогда закрылся бы еще один источник ошибок — проверки в начале функций.
Здравствуйте, DarkEld3r, Вы писали:
ARK>>А нужно ли оно? Отреагировать на панику ведь все равно никак нельзя. Поэтому просто можно считать, что ее нет. DE>Во первых, noexcept в плюсах предоставляет дополнительную информацию компилятору, а значит помогает оптимизациям.
В плюсах исключения, которые можно хватать и работать дальше, а в расте аборт.
DE>Во вторых, в минусы исключений записывается неявность — про панику точно так же из документации узнавать приходится.
Да вот я не пойму — а зачем?
DE>Ну и в третьих, "иногда" среагировать можно.
В расте? Не слышал. Но, ИМХО, это неправильно, по идее паника это паника.
Здравствуйте, AlexRK, Вы писали:
ARK>В плюсах исключения, которые можно хватать и работать дальше, а в расте аборт.
Не совсем аборт, по крайней мере, не аборт в плюсовом смысле — стек разматывается и деструкторы вызываются. Очевидно, для этого нужно дополнительные действия предпринимать, а для noexcept не нужно.
ARK>Да вот я не пойму — а зачем?
Как правило всё достаточно очевидно, но мне хочется заранее знать в каких случах что-то может пойти не так. Опять же, для стандартных функций старательно прописаны случаи возникновения паники. Даже в официальном мануале пару слов про соответствующее оформление документации есть. Значит не только мне это важным кажется.
ARK>В расте? Не слышал. Но, ИМХО, это неправильно, по идее паника это паника.
Можно обрабатывать на границе потоков. Так что при большом желании можно извернутсья и использовать как исключения, только вместо try будет thread.
Здравствуйте, DarkEld3r, Вы писали:
ARK>>В плюсах исключения, которые можно хватать и работать дальше, а в расте аборт. DE>Не совсем аборт, по крайней мере, не аборт в плюсовом смысле — стек разматывается и деструкторы вызываются. Очевидно, для этого нужно дополнительные действия предпринимать, а для noexcept не нужно.
Да, тогда согласен.
ARK>>Да вот я не пойму — а зачем? DE>Как правило всё достаточно очевидно, но мне хочется заранее знать в каких случах что-то может пойти не так. Опять же, для стандартных функций старательно прописаны случаи возникновения паники. Даже в официальном мануале пару слов про соответствующее оформление документации есть. Значит не только мне это важным кажется.
Хз. По-моему, это идею паники убивает, она действительно начинает рассматриваться как исключение (что-то обратимое).
ARK>>В расте? Не слышал. Но, ИМХО, это неправильно, по идее паника это паника. DE>Можно обрабатывать на границе потоков. Так что при большом желании можно извернутсья и использовать как исключения, только вместо try будет thread.
Интересно, зачем это сделано... Как пить дать, на основе этой фичи будут криво эмулировать исключения.
M>>В том, что никто не знает, что это за «нужное значение».
ARK>Ничего не понял. ARK>(Если что, говнокод, в том числе и "список любых типов любой сложности, внутренности или вложенности", можно написать на чем угодно.)
То, что это можно написать на чем угодно не дает индульгенции Расту.
ARK>>>Ах, внутри файл читается? Тогда будьте добры отреагировать на потенциальный сбой. M>>Каким образом, если исключений нет? ARK>Проверкой результата функции, представленного алгебраическим типом.
В итоге, любой функции, даже написанной через три месяца другим человеком четырьмя уровнями выше, придется столкнуться с тем, что возвращается не нужное значение, а никому не нужная обертка Result<список любых типов любой сложности, внутренности или вложенности>?
M>>>>Чем это хорошо? А ничем. ARK>>>Это хорошо тем, что все происходит _явно_ и видно в коде. M>>Да ничего там «явного». Будет две сотни try! и один общий Err("строка"). И иди разбирайся.
ARK>Как я понимаю, авторы раста рассчитывают на то, что код будет писаться в основном таким образом, чтобы избегать исключений где попало. Поэтому — в теории — не должно быть try везде, где только можно.
Чистые теоретики, что ли? На практике будет сотня try! со строкой в Err
DE>>Во вторых, в минусы исключений записывается неявность — про панику точно так же из документации узнавать приходится. ARK>Да вот я не пойму — а зачем?
Потому что в правильных языках даже паника — не причина убивать программу. В частности, если паника произойдет в другом потоке, хорошо бы из вызывающего потока узнать, почему она произошла (желательно — со стектрейсом, например).
Здравствуйте, Mamut, Вы писали:
DE>>>Во вторых, в минусы исключений записывается неявность — про панику точно так же из документации узнавать приходится. ARK>>Да вот я не пойму — а зачем?
M>Потому что в правильных языках даже паника — не причина убивать программу. В частности, если паника произойдет в другом потоке, хорошо бы из вызывающего потока узнать, почему она произошла (желательно — со стектрейсом, например).
В расте программа не убивается, убивается текущая задача.
M>Как это будет работать в расте?
Честно говоря, не знаю, есть ли там стектрейс, возможно, в дебаге есть какая-то подобная вещь. В релизе, уверен, не будет, потому что оптимизации.
В программе панику обработать нельзя, хотя выше DarkEld3r сообщил, что есть какая-то (сомнительная) возможность перехвата на границе потоков.
M>>Потому что в правильных языках даже паника — не причина убивать программу. В частности, если паника произойдет в другом потоке, хорошо бы из вызывающего потока узнать, почему она произошла (желательно — со стектрейсом, например).
ARK>В расте программа не убивается, убивается текущая задача.
Ну, если это произойдет в главном потоке, то убьется вся программа. Что тоже плохо.
M>>Как это будет работать в расте?
ARK>Честно говоря, не знаю, есть ли там стектрейс, возможно, в дебаге есть какая-то подобная вещь. В релизе, уверен, не будет, потому что оптимизации.
ARK>В программе панику обработать нельзя, хотя выше DarkEld3r сообщил, что есть какая-то (сомнительная) возможность перехвата на границе потоков.
А вот это очень и очень плохо. Каким бы смешным ни был пример про деление на ноль выше, а мы его один раз получили (где-то не стояли проверки на входящие значения). Exception заботливо был записан самым верхнеуровневым обработчиком в логи (включая входящие данные, стектрейс и т.п.), клиенту был отдан какой-то стандартизированный ответ.
Здравствуйте, Mamut, Вы писали:
M>Как это будет работать в расте?
Стектрейса не будет, будет возврат ошибки любого типа. Буквально — вернётся Any из которого потом реальный тип, насколько я знаю, не так-то и удобно доставать.
Здравствуйте, AlexRK, Вы писали:
ARK>В программе панику обработать нельзя, хотя выше DarkEld3r сообщил, что есть какая-то (сомнительная) возможность перехвата на границе потоков.
Вот возвращаемый тип, если что.
Здравствуйте, Mamut, Вы писали:
DM>> В Расте же есть нормальные алгебраические типы, и обработка ошибок строится как в хаскеле и прочих ML-ях: паттерн матчингом
M>То есть
M>
case a() of
_ -> сделай_что_то, невзирая на то, что был возвращен код ошибки?
end
Да, если возвращаемое значение тебе не важно, можно примерно так написать, даже короче. Но это вон как надо расстараться, сколько слов написать. Намеренный отказ от разбора ошибки все же не то же самое, что банальная забывчивость.
Ты удивишься, но сейчас в крупных франчах 1с (да да программисты 1с) дефакто запрещено использовать исключения и гото.
Лучше пусть вылетит ошибка(в том числе и в боевом режиме), чем некорректное поведение!
"Ясно, что быдлокодеры как сидели на шарпе так и будут сидеть"
Хотя... 
Так что подозреваю, что причина в другом. Опять же, авторы ссылаются и на другие языки.
