Здравствуйте, 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#-е.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, s22, Вы писали:
s22>Здравствуйте, VladD2, Вы писали:
VD>>И, вообще, чем они свои экстравагантные поступки то объясняют? Без ЖЦ все плохо?
s22>try catch относят к плохому стилю написания, как и goto s22>например на форуме gcc жаловались на то, что использование исключений серьезные создает проблемы с оптимизацией кода.
try catch — да, плохой стиль.
Правильный exception-safe код никаких try catch не содержит, все делается через RAII.
Здравствуйте, artelk, Вы писали:
C>>В Rust — невозможно. A>Т.е. исключение (потенциально бросаемое из функции) является частью сигнатуры этой функции? Чем это по сути отличается от явовских чекед исключений, от которых почти все плюются?
Да. От Java-вских исключений плюются по причине неудобности их использования, а сама идея очень здравая.
Здравствуйте, VladD2, Вы писали:
VD>>>Что такое DWARF maps? C>>Табличная обработка исключений, когда адрес обработчика указан для каждого места, где может возникнуть исключение. VD>Об этом где-то можно почитать? http://mortoray.com/2013/09/12/the-true-cost-of-zero-cost-exceptions/
VD>И вообще, какие аргументы против исключений, кроме того, что в С++ они не продуманы?
Сложность корректного unwinding'а.
VD>Без исключений ты должен будешь делать массу не относящихся к основному алгоритму проверок или засорять код опертором "?.", который в данном случае можно назвать "отвяжись".
Ага. Только это делается явно.
VD>Что является еще одной обузой. Прикинь, что будет с кодом, если в функции попарсить числа из строк, сходить в БД и т.п.? А что будет в тех функциях которые вызывают такие функции? VD>Получаются те же исключения, но которые постоянно заставляют программиста "приседать". Плюс производительность они просаживают не только в месте где try/catch/finally написан, а в любом месте вызова функции обрабатывающей ошибки.
Ну а что тогда делать, если уровнем выше надо проверить не упало ли всё из-за базы данных и в этом случае сделать failover на другой источник данных? Откуда ты узнаешь какой именно тип исключения и не изменит ли его завтра автор на обёрнутое исключение?
VD>Ну, как не страдает, когда почти все "фичи" — это попытка делать современный язык без GC. На фиг тогда нужны все эти явные времена жизни, ARC, отказ от исключений?
Это попытка сделать надёжный язык.
VD>Вот есть у меня функция, которая внутри которой получается строка, парсится как число и число дальше используется для вычислений. Эта функция вызвана через 100500 функций и в итоге я должен вывести пользователю (предположим, на консоль) результат вычислений. С исключениями я тупо реализую алгоритм. Если во входной строке не число, то в самом коре вызовов я перехвачу все исключения и выведу на консоль текст из исключения.
А теперь представь, что ты пишешь код файловой системы и при размотке стека тебе надо вернуть на место все изменения.
VD>При явной обработке ошибок я буду вынужден забить все возвращаемые значения сообщениями об ошибках. И еще по пресидать, чтобы обеспечить их совестимость и правильное протаскивание вниз.
Всё правильно. Иначе будет вариант, что пользователь рядом с полем ввода увидит сообщение "Failed to read /usr/share/tzinfo".
VD>Сейчас в MS VS одна из основных проблем — это куча COM-овского кода который вместо нормальной обработки ошибок тупо возвращает E_FAIL и причину ты уже не узнаешь никогда, если ты не знаком с кем-то из МС и он не посмотрит в исходниках.
В Rust возвращается типобезопасная ошибка, с возможностью запомнить её stack trace.
VD>Это распространение очередной надумано догмы. Давай ты мне покажешь обсуждение проблемы вызванной try/... в том же C#-е.
class CompoundRecord
{
private final FileInputStream stream1, stream2;
public CompoundRecord(String fname1, String fname2) {
stream1 = new FileInputStream(fname1);
try {
stream2 = new FileInputStream(fname2);
} finally {
stream1.close();
}
}
public void close()
{
stream1.close(); //А что если тут исключение будет?
stream2.close();
}
};
Здравствуйте, Cyberax, Вы писали:
C>А теперь представь, что ты пишешь код файловой системы и при размотке стека тебе надо вернуть на место все изменения.
Тебе транзакции нужны здесь. Исключения из другой оперы.
Здравствуйте, Cyberax, Вы писали:
C>Исключения можно забыть обработать (что бывает сплошь и рядом) — это основная причина отказа от них в Rust.
Это прекрасно! Отлично!
Я просто счастлив, из-за того, что оно так и есть, потому что: код возврата тоже можно забыть проверить, но ведёт это к куда более печальным последствиям, чем необработанное исключение, а всё потому, что искать ошибку в данных, ломая голову о причинах пересчёта погоды в Африке, куда хуже чем упавшая софтина, которая к тому же оставила стэк-трэйс в логе.
Фикус тут в том, что ловить и обрабатывать исключения нужно тогда, когда ты точно знаешь что ловить и как это обрабатывать, а иначе — пусть падает.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
C>>Исключения можно забыть обработать (что бывает сплошь и рядом) — это основная причина отказа от них в Rust. Ф>Это прекрасно! Отлично! Ф>Я просто счастлив, из-за того, что оно так и есть, потому что: код возврата тоже можно забыть проверить
В Rust нельзя забыть проверить код возврата.
Здравствуйте, Cyberax, Вы писали:
C>В Rust нельзя забыть проверить код возврата.
Да ладно?
let x = fooWhichReturnError();
x?.Bar();
return 42;
И еще ладно бы забыть случайно или намеренно! Но в жизни же бывают случаи, кода ты будешь вынужден "забыть" свои коды. Вот нужно тебе реализовать интерфейс не предусматривающий код возврата, но при его реализации ты вынужден вызвать функции с кодами возврата. Что делать? Только "забыть".
Или интерфейс предусматривает один код, а функции возвращают другие коды. Значит мы сидим и препаковываем. И это еще в лучшем случае, так как исходный код может не позволять сохранить данные из полученного.
Короче, тупиковый путь. И к чему он ведет отлично видно по COM-у. Там просто возвращают если что универсальный E_FAIL и понять реальную причину невозможно.
Далее отладка. Так я включаю перехват исключений и вижу место возникновения ошибки. С кодами возврата так не выйдет. Это же ординарный код.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>И еще ладно бы забыть случайно или намеренно! Но в жизни же бывают случаи, кода ты будешь вынужден "забыть" свои коды. Вот нужно тебе реализовать интерфейс не предусматривающий код возврата, но при его реализации ты вынужден вызвать функции с кодами возврата. Что делать? Только "забыть".
Подозреваю, что будет практиковаться дописывание "throws Exception" ко всем сигнатурам методов. Следующим шагом объявят это дописывание поведением по умолчанию и поручат компилятору. Вышеприведенный "Error(e) => return Error(e);" будет также по умолчанию вставлятся везде, где явно не будет написан catch (или его растовый аналог). Потом сделают сохранение информации о стеке вызовов. Короче, переизобретут обычные исключения.
Здравствуйте, artelk, Вы писали:
C>>В Rust нельзя забыть проверить код возврата. A>А если функция "возвращает" void? Будет ли компилятор заставлять мачтить Result<void, Error>?
К.О. подсказывает, что если функция возвращает void, то она не может возвращать код ошибки.
Здравствуйте, VladD2, Вы писали:
VD>let x = fooWhichReturnError(); VD>x?.Bar();
Тут явно пробрасывается исключение.
VD>Далее отладка. Так я включаю перехват исключений и вижу место возникновения ошибки. С кодами возврата так не выйдет. Это же ординарный код.
В Error запоминается место создания, не проблема.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, в D есть проблемы с исключениями в деструкторах?
Еще какие! Деструктор же нередко вызывается сборщиком мусора, а в этот момент низя выделять память в егойной куче, поэтому "new Exception" вызывает кирдык — вылет с InvalidMemoryOperationError.
