Здравствуйте, VladD2, Вы писали:
VD>Мне вот интересно что в Расте с делением на 0 происходит. Тупо халтят всю программу?
Будет паника, да.
Только паника всё-таки вызывает деструкторы, ну и если она была не в главном потоке, то можно обработать.
Здравствуйте, DarkEld3r, Вы писали:
DE>Будет паника, да. DE>Только паника всё-таки вызывает деструкторы, ну и если она была не в главном потоке, то можно обработать.
А, если у меня навернулась совсем не критичный метод, но в главном потоке, то программа закроется?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Основная проблема с кодами возврата не контроль компилятора, а куча болепрлэйт-кода засоряющего код, и необходимость тратить на него время. Людям нужно писать основной алгоритм, а их компилятор заставляет отвлегаться на какие-то не относящиеся к его суди мелочи. Причем, зачастую, таких мелочей может быть очень много.
Все так. Это осознанное их решение — весь раст пронизан духом максимально явного и подробного прописывания всех деталей. Многое из того, что в других языках делается на умолчаниях и на автомате, в расте намеренно заставляют программиста описывать явно. Так они надеются уменьшить число багов в коде на расте. Языков, где "нужно писать основной алгоритм" без мелочей, и так хватает.
Здравствуйте, VladD2, Вы писали:
VD>А, если у меня навернулась совсем не критичный метод, но в главном потоке, то программа закроется?
Если под "навернулась" понимать растовую "панику" (типа деления на ноль), то да. В общем случае, панику и не предполагается обрабатывать, это что-то типа assert/abort. Да, кто-то может кидать панику из либы и пользователь библиотеки обработать это не сможет, но так делать не принято.
Я не то чтобы защищаю отказ от исключений, но в том же С++ при наличии исключений, деление на ноль тоже нельзя перехватить средствами языка.
Здравствуйте, D. Mon, Вы писали:
DM>Все так. Это осознанное их решение — весь раст пронизан духом максимально явного и подробного прописывания всех деталей. Многое из того, что в других языках делается на умолчаниях и на автомате, в расте намеренно заставляют программиста описывать явно.
Ну так обязали бы как-то помечать функции, которые могут кидать (что угодно). А то сейчас ты никак не можешь знать возможна ли паника при вызове произвольной функции. То есть аналога плюсового nothrow нет. А в плане гарантий паника даже хуже исключений так как обработать нельзя (в общем случае). Если, конечно, нас не устраивает "гарантированное падение, если что-то пошло не так".
Здравствуйте, VladD2, Вы писали:
VD>"Здесь" управление просто не появится. Соответственно никаких проблем ни _myArray, ни с item не будет.
Ну да, понятно, что здесь не появится. Но _myArray — это поле, и оно испорчено. Проблема проявится в другом методе, если этот объект не будет разрушен.
VD>Кстати, _myArray будет во все том же состоянии, так как во время итераций его изменять нельзя. Вот в item может быть фигня. Только она будет в нем не зависимо от того произошло ли исключение или обработка кодов возвратов. Чтобы избежать этого нужны какие-то транзакционные системы. Коды возврата проблему не полной инициализации не решают никак.
Да, я имел в виду именно состояние объектов внутри _myArray, а не сам массив. Половина из них изменена, другая — нет.
VD>Основная проблема с кодами возврата не контроль компилятора, а куча болепрлэйт-кода засоряющего код, и необходимость тратить на него время. Людям нужно писать основной алгоритм, а их компилятор заставляет отвлегаться на какие-то не относящиеся к его суди мелочи. Причем, зачастую, таких мелочей может быть очень много. В языке без контроля использования возвращаемых значений это порождает дырявый код. В языка с контролем возвращаемых значений — это превращается в Ад для программиста.
Да, панацеи нет. Мое изначальное замечание было именно об этом. Обработка ошибок обладает природной сложностью и серебряной пули для нее пока не придумали. Коды возврата (в том числе проверяемые компилятором) обладают своими недостатками, исключения — своими.
VD>Никаких проблем с инвариантами, при этом, не возникает, так как все порожденные в процессе работы данные попросту выбрасываются.
Возникают в тех местах, где данные таки не выбрасываются.
Здравствуйте, VladD2, Вы писали:
VD>Не видим, так как тебе этими типами нужно будет утыкать все возвращаемые значения всех функций вызывающие эту.
Как это не видим, когда видим в заголовке функции?
Утыкать придется, верно.
VD>Это вообще пипец! И об этом тебе уже говорили. Явские checked exception доказали свою полную непригодность для реальной жизни. Геморрой вызываемый ими нивелируют все их гипотетические преимущества.
ИМХО, checked exceptions все же гораздо многословнее растовского варианта. Но смысл примерно тот же, да.
VD>Не видим, так как этим дело мужно обложить каждую строчку кода. По сути — это закат солнца вручную (эмуляция исключений на кодах возврата). Вот это ваше try!() — это чистой воды болерплэйт. Просто его немного засахарили.
Я думаю, что просто исключения не должны летать где попало, и раст предоставляет для этого средства. Это в дотнете откуда угодно может вылететь NullReferenceException. Раст ориентирует на создание безопасных подмножеств кода, где никаких исключений нет. Поэтому ваши рассуждения про закат не вполне корректны.
VD>Вранье! Здесть или не будет управления или он будет в испорченном состоянии, но мы не будет знать об этом, так как где-то выше проигнорировали или неверно обработали код возврата.
Не надо нервничать. Я немного ошибся — имел в виду не эту точку, а любые другие методы объекта, использующие испорченное поле после вылета исключения.
Можно было бы и догадаться, идея не бог весть какая сложная.
VD>Итого, мне очевидно, что ты не смог доказать ни одного из своих утверждений. Мой тебе совет признать ошибочность своего мнения, а не упираться рогом.
А очевидно другое — что вы не хотите понять, о чем я говорю.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, у этого метода есть еще одно неприятное следствие. Вот представь себе, написал ты свой метод ProcessInternal год назад. В то время необходимости обработки ошибок в нем не было. Заиспользовал ты его в сотне мест, из сотни других функций. И вдруг, у тебя малость изменились условия и где-то этот методу потребовалось записать пару байт в файл. Файл этот обязан быть на диске в некотором каталоге. Но ведь файл могут нечаянно грохнуть или место на диске может кончиться, а приложение — это сервер который дергает GUI-ёвое приложение, и ошибку нужно показать в этом самом GUI-е. Что делать будем?
VD>Правильно! Нужно долго и нудно протаскивать код возврата через все методы где использована эта функция.
Кстати, у этого метода есть еще одно неприятное следствие. Вот представь себе, написал ты свой метод ProcessInternal год назад. В то время необходимости ветвления обработки в нем не было. Заиспользовал ты его в сотне мест, из сотни других функций. И вдруг, у тебя малость изменились условия и где-то этот методу потребовалось вычислить дополнительно интеграл Пуассона. Что делать будем?
Правильно! Нужно долго и нудно протаскивать дополнительный параметр через все методы где использована эта функция.
Да, вынесение ошибок в заголовок функции имеет и плюсы, и минусы. В каких-то классах приложений предпочтительнее не выносить, в каких-то выносить.
Здравствуйте, VladD2, Вы писали:
ARK>>В принципе, согласен с этим. Плюс, который я вижу — таки явный "try!", который можно тупо найти поиском. VD>В реальном приложении у тебя этих явных траев будет 100500 на каждом шагу и поиск будет попросту бесполезен.
Думаю, что код на расте надо писать так, чтобы ошибки были сконсолидированы в одном кластере кода. То бишь не вызывать чтение файлов в методе вычисления дифференциальных уравнений. Тогда и 100500 траев не будет. ИМХО.
VD>Мне вот интересно что в Расте с делением на 0 происходит. Тупо халтят всю программу?
Здравствуйте, DarkEld3r, Вы писали:
DE>Ну так обязали бы как-то помечать функции, которые могут кидать (что угодно). А то сейчас ты никак не можешь знать возможна ли паника при вызове произвольной функции. То есть аналога плюсового nothrow нет.
А нужно ли оно? Отреагировать на панику ведь все равно никак нельзя. Поэтому просто можно считать, что ее нет.
Здравствуйте, DarkEld3r, Вы писали:
DE>Ну так обязали бы как-то помечать функции, которые могут кидать (что угодно). А то сейчас ты никак не можешь знать возможна ли паника при вызове произвольной функции.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, DarkEld3r, Вы писали:
DE>>Ну так обязали бы как-то помечать функции, которые могут кидать (что угодно). А то сейчас ты никак не можешь знать возможна ли паника при вызове произвольной функции. То есть аналога плюсового nothrow нет.
ARK>А нужно ли оно? Отреагировать на панику ведь все равно никак нельзя. Поэтому просто можно считать, что ее нет.
сохранение дампа....
если дамп будет можно относительно легко читать(сделают тузлу) в дебуг варианте..... то это более информативно, чем исключения
Здравствуйте, D. Mon, Вы писали:
DM>Все так. Это осознанное их решение — весь раст пронизан духом максимально явного и подробного прописывания всех деталей. Многое из того, что в других языках делается на умолчаниях и на автомате, в расте намеренно заставляют программиста описывать явно. Так они надеются уменьшить число багов в коде на расте. Языков, где "нужно писать основной алгоритм" без мелочей, и так хватает.
Говноязыков в которых приходится мучиться чтобы чуть-чуть отрефакторить код или написать новый вообще выше крыши.
И не ясно зачем они тогда седелали макросы. Ведь макросы как раз призваны скрывать болерплэйт. Вот эти все Try! — это ведь тоже сокрытие деталей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, DarkEld3r, Вы писали:
DE>Если под "навернулась" понимать растовую "панику" (типа деления на ноль), то да. В общем случае, панику и не предполагается обрабатывать, это что-то типа assert/abort. Да, кто-то может кидать панику из либы и пользователь библиотеки обработать это не сможет, но так делать не принято.
"Не принято" — это зачет!
DE>Я не то чтобы защищаю отказ от исключений, но в том же С++ при наличии исключений, деление на ноль тоже нельзя перехватить средствами языка.
Дык, все ненавистники исключений обычно и имеют опыт их использования исключительно на С++. Возможно, если бы авторы того же Раста по пользовались бы языками где исключения реализованы качественно, у них и не возникло бы желания возвращаться в прошлые века и городить сахар над кодами возврата.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AlexRK, Вы писали:
ARK>Ну да, понятно, что здесь не появится. Но _myArray — это поле, и оно испорчено. Проблема проявится в другом методе, если этот объект не будет разрушен.
ОК, так как коды возврата позволят нам избежать ошибок в подобном случае?
ARK>Да, я имел в виду именно состояние объектов внутри _myArray, а не сам массив. Половина из них изменена, другая — нет.
Ну, дык, и причем тут исключения? Если ты написал ошибочный код, то ты можешь нарушить инварианты. Коды возврат тут ничем не отличаются. Ни то, ни другое тут просто не причем.
ARK>Да, панацеи нет.
О, да, КО!
ARK>Мое изначальное замечание было именно об этом. Обработка ошибок обладает природной сложностью и серебряной пули для нее пока не придумали. Коды возврата (в том числе проверяемые компилятором) обладают своими недостатками, исключения — своими.
Опять голословные утверждения. Преимущества исключений перед кодами возврата тебе показали. Обратного ты продемонстрировать не смог, но с упрямостью достойной лучшего применения ты продолжать повторять ошибочные заявления.
Ну, что на это можно сказать? Продолжай верить в откровенную чушь. Только нам больше про это не рассказывай. Будут аргументы, заходи. А, повторять в сотый раз голословные утверждения не надо.
VD>>Никаких проблем с инвариантами, при этом, не возникает, так как все порожденные в процессе работы данные попросту выбрасываются.
ARK>Возникают в тех местах, где данные таки не выбрасываются.
Ну, не пиши глупый код. С исключением это просто. Делай обработку только в самом корне приложения или там где ты можешь восстановиться. Это совсем не сложно.
Коды возвратов тебе все равно ничем тут не помогут.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну, дык, и причем тут исключения? Если ты написал ошибочный код, то ты можешь нарушить инварианты. Коды возврат тут ничем не отличаются. Ни то, ни другое тут просто не причем.
Коды возврата в стиле Rust всегда видны в коде — вот это мне нравится.
Исключения почти всегда не видны, а коды ошибок не видны, когда программист их забыл проверить.
То бишь "забыть" о проблемах с инвариантами, когда компилятор явно тебе предписывает обработать ошибку, гораздо сложнее, чем 1) в случае с обычными ретурн кодами (можем забыть проверить); 2) с исключениями (можем быть вообще не в курсе, что они тут пролетают).
Здравствуйте, AlexRK, Вы писали:
ARK>Как это не видим, когда видим в заголовке функции?
У тебя чуть менее чем все функции будут возвращать Result.
ARK>ИМХО, checked exceptions все же гораздо многословнее растовского варианта. Но смысл примерно тот же, да.
Та же фигня. Но это хотя бы исключения. Их хотя бы не надо вручную протаскивать везде.
ARK>Я думаю, что просто исключения не должны летать где попало, и раст предоставляет для этого средства.
Не бросай их где попало и они не будут летать где попало. Ваш, КО.
ARK>Это в дотнете откуда угодно может вылететь NullReferenceException. Раст ориентирует на создание безопасных подмножеств кода, где никаких исключений нет. Поэтому ваши рассуждения про закат не вполне корректны.
Ну, не бывает безопасных подмножеств кода. Не бывает. То что ты сделал обработку ошибок явной не сделало твой код правильным. Везде где в дотнете может прилететь исключение у тебя будут возвращаемые значения обернуты в Resalt или твоя программа будет выпадать в осадок потому что не может обработать аппаратное исключение. Надежности от этого не прибавится ни на байт.
ARK>Я немного ошибся — имел в виду не эту точку, а любые другие методы объекта, использующие испорченное поле после вылета исключения. ARK>Можно было бы и догадаться, идея не бог весть какая сложная.
Идеи просто нет. Ты или показываешь случае которые могут вызвать одинаковые проблемы и при кодах возврата, и при исключениях, или говоришь вещи не соответствующие действительности. Но другого и не может быть, так как ты пытаешься доказать неверное утверждение.
ARK>А очевидно другое — что вы не хотите понять, о чем я говорю.
Нет, уж. Или ты не можешь сформулировать мысль, или у тебя ее просто нет, а есть некое туманное ощущение. Лично я склоняюсь ко второму.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AlexRK, Вы писали:
ARK>Кстати, у этого метода есть еще одно неприятное следствие. Вот представь себе, написал ты свой метод ProcessInternal год назад. В то время необходимости ветвления обработки в нем не было. Заиспользовал ты его в сотне мест, из сотни других функций. И вдруг, у тебя малость изменились условия и где-то этот методу потребовалось вычислить дополнительно интеграл Пуассона. Что делать будем?
Нет, батенька, ты путаешь основную логику приложения и логику обработки исключительных ситуаций, которая к ней отношения не имеет. Весь смысл в том, что в нормальных условиях твоя программа будет работать вообще без обработки исключений или кодов возвратов. В языке с исключениями ты и пишешь весь код так, как-будто ошибок быть не может. В языке же с кодами возвратов ты тратишь тучу времени на поддержание инфраструктуры обработки ошибок, а значит сложность в твоих программах нарастает быстрее и ты потратишь значительно больше усилий на создание аналогичной программы, чем я.
ARK>Правильно! Нужно долго и нудно протаскивать дополнительный параметр через все методы где использована эта функция.
Вот я и буду логикой заниматься, а ты обработкой кодов.
ARK>Да, вынесение ошибок в заголовок функции имеет и плюсы, и минусы. В каких-то классах приложений предпочтительнее не выносить, в каких-то выносить.
Нет никаких плюсов. Ну, нет. Покажи мне эти плюсы, если ты их видишь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AlexRK, Вы писали:
VD>>Мне вот интересно что в Расте с делением на 0 происходит. Тупо халтят всю программу?
ARK>По-моему, халт текущей задачи.
Печально. Это значит, что приложения будут тихо схлопываться вместо того чтобы дать диагностику и продолжить работу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
DM>Я не пойму, почему при обсуждении Раста исключениям по старинке противопоставляют коды возврата. В Расте же есть нормальные алгебраические типы, и обработка ошибок строится как в хаскеле и прочих ML-ях: паттерн матчингом, там забыть что-то обработать компилятор не даст. Это вообще не коды ошибок, нет смысла даже сравнивать.
То есть
case a() of
_ -> сделай_что_то, невзирая на то, что был возвращен код ошибки?
end
