Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, s22, Вы писали:
s22>>Будет ли в Немерли 2.0 в базовом промежуточном языке try catch?
H>Очевидно — при компиляции в .NET их поддерживать строго обязательно
Поэтому был вопрос.
Что будет в базовом языке? Или от него отказались?
Здравствуйте, s22, Вы писали:
s22>Как таковую фичу try catch удаляют уже из второго современного языка. (rust swift)
Мои им соболезнования. Код без исключений печальный, а качество обработки ошибок низкое.
В прочем, говорить серьезно о Расте просто глупо. Язык еще формируется. Это пока что экспериментальный проект. Они в нем еще 100 раз все периграют (как уже переигрывали). И не факт, что язык вообще выйдет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, s22, Вы писали:
s22>Будет ли в Немерли 2.0 в базовом промежуточном языке try catch?
Будет. Это вообще фича полезная. В любом случае, тем кто хочет писать без них они не помешают.
Тут только назревает один маленький казус. В Немерле 2.0 скорее всего вообще не будет базового языка как такового. Весь язык будет "в бибилотеке". Так что базовым Немерле 2.0 будет то что мы в нее положим.
Разве что можно будет выделить конструкции переписываемые в другие конструкции языка или в более низкоуровневый язык. В Немерле 1.х большая часть языка бала захардкожена.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
s22>>Как таковую фичу try catch удаляют уже из второго современного языка. (rust swift) VD>Мои им соболезнования. Код без исключений печальный, а качество обработки ошибок низкое.
1) В Rust будет синтаксический сахар для проверки.
То есть:
fn something() -> int throws Error
{
...
}
Будет эквивалентно:
fn something() -> Result<int, Error> {...}
Затем можно будет делать так:
fn anything() -> int throws Error
{
let res = hello?.something()
}
Это разсахарится в:
fn anything() -> Result<int, Error>
{
res = match hello.something() {
Error(e) => return Error(e);
_ => _
}
}
Здравствуйте, Cyberax, Вы писали:
C>1) В Rust будет синтаксический сахар для проверки. C>... C>Там ещё есть try! и другой сахар. См.: https://github.com/rust-lang/rfcs/pull/243
И зачем нужен этот полу-ручной аналог нормальных исключений?
Во-первых, это тормоза, так как возврат сложного объекта ни разу не бесплатен (int, то через регистр спокойно возвращается).
Во-вторых, это будет засорять код.
А результат будет примерно тем же что с исключениями.
C>Плюсов несколько — явная спецификация возвращаемых ошибок и невозможность просто так их проигнорировать.
Ну, изобрели орлы монаду meybi/option. Зачем?
C>2) В Rust есть исключения (fail'ы) на уровне задач.
И с чем их едят?
И, вообще, чем они свои экстравагантные поступки то объясняют? Без ЖЦ все плохо?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
C>>Там ещё есть try! и другой сахар. См.: https://github.com/rust-lang/rfcs/pull/243 VD>И зачем нужен этот полу-ручной аналог нормальных исключений? VD>Во-первых, это тормоза, так как возврат сложного объекта ни разу не бесплатен (int, то через регистр спокойно возвращается).
Тормозов там особо нет, в будущем планируется использовать DWARF maps для редких исключений.
VD>Во-вторых, это будет засорять код.
Не будет, благодаря сахару.
C>>2) В Rust есть исключения (fail'ы) на уровне задач. VD>И с чем их едят? VD>И, вообще, чем они свои экстравагантные поступки то объясняют? Без ЖЦ все плохо?
GC вообще пофиг.
Смысл в том, что они хотят избежать неявного unwinding'а. Аргумент такой, что правильно писать exception-safe код очень сложно, и почти всегда оно сводится к перехватыванию исключений на каком-то верхнем уровне и вывод их в лог. В результате, система может остаться в непонятном состоянии. Вдобавок, есть вечная проблема с исключениями внутри деструкторов.
Потому и получается, что задачи представляют натуральный барьер для ограничения fail'ов. После отправки fail'а его нельзя перехватить внутри задачи, так что исключения внутри деструкторов не имеют последствий — "помэрла так помэрла". Тут полная аналогия с Erlang'ом.
Здравствуйте, VladD2, Вы писали:
VD>И, вообще, чем они свои экстравагантные поступки то объясняют? Без ЖЦ все плохо?
try catch относят к плохому стилю написания, как и goto
например на форуме gcc жаловались на то, что использование исключений серьезные создает проблемы с оптимизацией кода.
Здравствуйте, s22, Вы писали:
VD>>И, вообще, чем они свои экстравагантные поступки то объясняют? Без ЖЦ все плохо?
s22>try catch относят к плохому стилю написания
Здравствуйте, s22, Вы писали:
s22>try catch относят к плохому стилю написания, как и goto
Не слушай глупцов с однобоким опытом.
s22>например на форуме gcc жаловались на то, что использование исключений серьезные создает проблемы с оптимизацией кода.
Предлагаю не обсуждать здесь проблемы возникающие у людей упорно использующих кривые языки.
Накие проблемы с исключениями в дотнете и яве?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Тормозов там особо нет, в будущем планируется использовать DWARF maps для редких исключений.
Что такое DWARF maps?
VD>>Во-вторых, это будет засорять код. C>Не будет, благодаря сахару.
Ну, как же не будет, когда этот сахар совершенно лишний? Ты же сам показал все эти "?." на ровном месте. И их будет 100500. Любой динамический ввод и все функции по кол-стеку будут пестрить этими "?.". Тогда уж их надо автоматом вставлять, чтобы не видно было. Но в чем тогда разница с исключениями? И как это может быть быстрее них?
C>GC вообще пофиг.
Да, я смотрю как он пофиг. Весь язык приседаниями набили из-за его отсутствия.
C>Смысл в том, что они хотят избежать неявного unwinding'а. Аргумент такой, что правильно писать exception-safe код очень сложно, и почти всегда оно сводится к перехватыванию исключений на каком-то верхнем уровне и вывод их в лог.
Эти два утверждения противоречат друг-другу. Или "очень сложно", или "сводится к перехватыванию исключений на каком-то верхнем уровне и вывод их в лог".
Собственно это и есть разумная стратегия их обработки. Перехватывает там можем восстановиться или даже не перехватываем вовсе.
C>В результате, система может остаться в непонятном состоянии.
Это какой-то миф. Моей практикой это ни разу не подтверждается. Или ты обработал исключение и состояние совершенно определенное, или не обработал и тогда его вовсе нет.
C>Вдобавок, есть вечная проблема с исключениями внутри деструкторов.
Зачем делать выводы на базе языка старого как говно мамонта, автор которое упертый как баран? finally изобрели 100 лет назад. Он решает все проблемы. Да и конструкторы сами по себе вещь сорная. При наличии автоматического управления памятью она не особо нужны.
C>Потому и получается, что задачи представляют натуральный барьер для ограничения fail'ов. После отправки fail'а его нельзя перехватить внутри задачи, так что исключения внутри деструкторов не имеют последствий — "помэрла так помэрла". Тут полная аналогия с Erlang'ом.
Это очередная догма. Бывает 100500 случаев. Где-то можно. Где-то нельзя. Я бы еще понял, если бы они сделали особый режим который можно было бы применять в некотором классе задач. Ну, там пометить функцию как не генерирующую исключения. Но просто лишать людей достижений компьюетрной науки — это маразм.
Кстати, в D есть проблемы с исключениями в деструкторах?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
C>>Тормозов там особо нет, в будущем планируется использовать DWARF maps для редких исключений. VD>Что такое DWARF maps?
Табличная обработка исключений, когда адрес обработчика указан для каждого места, где может возникнуть исключение.
VD>Ну, как же не будет, когда этот сахар совершенно лишний? Ты же сам показал все эти "?." на ровном месте. И их будет 100500. Любой динамический ввод и все функции по кол-стеку будут пестрить этими "?.". Тогда уж их надо автоматом вставлять, чтобы не видно было. Но в чем тогда разница с исключениями? И как это может быть быстрее них?
Исключения можно забыть обработать (что бывает сплошь и рядом) — это основная причина отказа от них в Rust. Вдобавок, ?. требует правильного описания формата возможных исключений в сигнатуре.
C>>GC вообще пофиг. VD>Да, я смотрю как он пофиг. Весь язык приседаниями набили из-за его отсутствия.
От отсутствия GC там вообще ничего не страдает. Скорее наоборот, для возможности использования GC делаются нехилые присядания.
C>>Смысл в том, что они хотят избежать неявного unwinding'а. Аргумент такой, что правильно писать exception-safe код очень сложно, и почти всегда оно сводится к перехватыванию исключений на каком-то верхнем уровне и вывод их в лог. VD>Эти два утверждения противоречат друг-другу. Или "очень сложно", или "сводится к перехватыванию исключений на каком-то верхнем уровне и вывод их в лог".
Проблема в промежуточных уровнях, которые исключение пролетает.
C>>Вдобавок, есть вечная проблема с исключениями внутри деструкторов. VD>Зачем делать выводы на базе языка старого как говно мамонта, автор которое упертый как баран? finally изобрели 100 лет назад. Он решает все проблемы. Да и конструкторы сами по себе вещь сорная. При наличии автоматического управления памятью она не особо нужны.
Не решает finally ничерта. Выброс исключения внутри finally — прямой аналог выбросу из деструктора, ровно с теми же проблемами.
VD>Это очередная догма. Бывает 100500 случаев. Где-то можно. Где-то нельзя. Я бы еще понял, если бы они сделали особый режим который можно было бы применять в некотором классе задач. Ну, там пометить функцию как не генерирующую исключения. Но просто лишать людей достижений компьюетрной науки — это маразм.
Я бы не называл исключения особым достижением. Скорее это кривой хак.
VD>Кстати, в D есть проблемы с исключениями в деструкторах?
Да. Те же самые.
Здравствуйте, Cyberax, Вы писали:
C>Исключения можно забыть обработать (что бывает сплошь и рядом) — это основная причина отказа от них в Rust.
А код возврата забыть проверить невозможно чтоли?
Здравствуйте, artelk, Вы писали:
C>>Исключения можно забыть обработать (что бывает сплошь и рядом) — это основная причина отказа от них в Rust. A>А код возврата забыть проверить невозможно чтоли?
В Rust — невозможно.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, artelk, Вы писали:
C>>>Исключения можно забыть обработать (что бывает сплошь и рядом) — это основная причина отказа от них в Rust. A>>А код возврата забыть проверить невозможно чтоли? C>В Rust — невозможно.
Т.е. исключение (потенциально бросаемое из функции) является частью сигнатуры этой функции? Чем это по сути отличается от явовских чекед исключений, от которых почти все плюются?
Здравствуйте, Cyberax, Вы писали:
VD>>Что такое DWARF maps? C>Табличная обработка исключений, когда адрес обработчика указан для каждого места, где может возникнуть исключение.
Об этом где-то можно почитать?
И вообще, какие аргументы против исключений, кроме того, что в С++ они не продуманы?
C>Исключения можно забыть обработать (что бывает сплошь и рядом) — это основная причина отказа от них в Rust.
Они и сделаны, чтобы их не обрабатывать где попало. А забыть можно все что угодно... там функцию вызвать или if вставить. Это не повод выбрасывать все это.
Без исключений ты должен будешь делать массу не относящихся к основному алгоритму проверок или засорять код опертором "?.", который в данном случае можно назвать "отвяжись".
C>Вдобавок, ?. требует правильного описания формата возможных исключений в сигнатуре.
Что является еще одной обузой. Прикинь, что будет с кодом, если в функции попарсить числа из строк, сходить в БД и т.п.? А что будет в тех функциях которые вызывают такие функции?
Получаются те же исключения, но которые постоянно заставляют программиста "приседать". Плюс производительность они просаживают не только в месте где try/catch/finally написан, а в любом месте вызова функции обрабатывающей ошибки.
C>>>GC вообще пофиг. VD>>Да, я смотрю как он пофиг. Весь язык приседаниями набили из-за его отсутствия. C>От отсутствия GC там вообще ничего не страдает. Скорее наоборот, для возможности использования GC делаются нехилые присядания.
Ну, как не страдает, когда почти все "фичи" — это попытка делать современный язык без GC. На фиг тогда нужны все эти явные времена жизни, ARC, отказ от исключений?
VD>>Эти два утверждения противоречат друг-другу. Или "очень сложно", или "сводится к перехватыванию исключений на каком-то верхнем уровне и вывод их в лог". C>Проблема в промежуточных уровнях, которые исключение пролетает.
Какая проблема?
Вот есть у меня функция, которая внутри которой получается строка, парсится как число и число дальше используется для вычислений. Эта функция вызвана через 100500 функций и в итоге я должен вывести пользователю (предположим, на консоль) результат вычислений. С исключениями я тупо реализую алгоритм. Если во входной строке не число, то в самом коре вызовов я перехвачу все исключения и выведу на консоль текст из исключения.
При явной обработке ошибок я буду вынужден забить все возвращаемые значения сообщениями об ошибках. И еще по пресидать, чтобы обеспечить их совестимость и правильное протаскивание вниз.
Ты шутишь?
Я сыт ручной обработкой ошибок. Я ее наелся еще во времена, когда в MS C++ не было исключений и когда с COM-ом возился. Мы тоже придумывали разные макросы и т.п. Но все это было убого.
Сейчас в MS VS одна из основных проблем — это куча COM-овского кода который вместо нормальной обработки ошибок тупо возвращает E_FAIL и причину ты уже не узнаешь никогда, если ты не знаком с кем-то из МС и он не посмотрит в исходниках.
Сахором — это конечно здорово, но лучше бы уж иметь куда более удобное решение.
C>Не решает finally ничерта. Выброс исключения внутри finally — прямой аналог выбросу из деструктора, ровно с теми же проблемами.
От обычных искючений нет никаких проблем. От ThreadAbort и OutOfMemory когда могут прилететь откуда угодно критичные места защищаются CER-ами. Нужно это с частотой приближающейся к нулю и связано с ручной обработкой неуправляемых ресурсов, которые в управляемых средах обычно обертываются обертками и далее проблем не вызывают.
C>Я бы не называл исключения особым достижением. Скорее это кривой хак.
Это распространение очередной надумано догмы. Давай ты мне покажешь обсуждение проблемы вызванной try/... в том же C#-е.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
