@hirthwork Мёртворождённый здесь ты, луддит со своим устаревшим говном. Есть GADT, Maybe и удобный синтаксис с chained style и кложурами (unwrap, unwrap_or, etc), не хуже чем монады в хаскиле получается. Может и монады запилят.
@hirthwork Ты дебил? Там в целом очень прагматичные чуваки оценивали плюсы/минусы от исключений и пришли к выводу, что нахуй надо. Конечном, мамкиным специалистам вроде тебя виднее, что надо использовать.
И да, жду ответа на /KUE
@anonymous@hirthwork прав. Если бы panic! был checked, как это реализовано с unsafe, описанной фигни, когда код проверки паники занимает большую часть программы, не было бы.
@o01eg Исключения через panic/recover это хуйня уровня го, когда создатели ступили поначалу, а потом решили всё-таки какое-то подобие выхода из сильно вложенных цепочек запилить, чтобы совсем язык не просасывал. В Rust эта хуйня не нужна, есть средства удобнее.
Ты ещё скажи что setjmp/longjmp это исключения.
@anonymous ну давай по пунктам разберём по ссылке написанное) складывается ощущение что авторы по жизни обиженные, про таких говорят что Брин не хотел, а Пэйдж не старался))
When you add a throw statement to an existing function, you must examine all of its transitive callers.
Ничего не должен, потому что для checked exceptions компилятор сам скажет, где эксепшен забыли обработать или пробросить
functions may return in places you don't expect
Тупо похуй где они вернут, главное что. И в случае checked exceptions явно указывается какие исключения могут возникнуть в конкретной функции
Lots of supporting machinery is needed to make writing correct exception-safe code easy.
Какая разница, где чистить ресурсы в goto statement или в finally? Только checked exceptions и try-with-resources делают многие вещи автоматическими
Turning on exceptions adds data to each binary produced, increasing compile time (probably slightly) andpossibly increasing address space pressure.
Пиздёж без пруфов и бенчмарков
For example, invalid user input should not cause exceptions to be thrown
Вот это вообще пушка. Какая им разница, как парсер запроса сообщит наружу об ошибке? Это уже приблуда, которая response генерит пусть перехватит эксепшен и сообщит юзеру, что он мудак. А во внутренние дела парсера пусть не лезет. Эксепшены как раз и прудуманы для того чтобы делегировать обработку ошибок кому надо.
В общем, тебе нужно много думать о своём поведении, стремиться к пробуждению сознания)
мертворождённый язык без checked exceptions
@anonymous тебя мама не учила, что от онанизма подростки слепнут? все эти Cons имеют слабое отношение к checked exceptions
@anonymous ну давай по пунктам разберём по ссылке написанное) складывается ощущение что авторы по жизни обиженные, про таких говорят что Брин не хотел, а Пэйдж не старался))
Ничего не должен, потому что для checked exceptions компилятор сам скажет, где эксепшен забыли обработать или пробросить
Тупо похуй где они вернут, главное что. И в случае checked exceptions явно указывается какие исключения могут возникнуть в конкретной функции
Какая разница, где чистить ресурсы в goto statement или в finally? Только checked exceptions и try-with-resources делают многие вещи автоматическими
Пиздёж без пруфов и бенчмарков
Вот это вообще пушка. Какая им разница, как парсер запроса сообщит наружу об ошибке? Это уже приблуда, которая response генерит пусть перехватит эксепшен и сообщит юзеру, что он мудак. А во внутренние дела парсера пусть не лезет. Эксепшены как раз и прудуманы для того чтобы делегировать обработку ошибок кому надо.
В общем, тебе нужно много думать о своём поведении, стремиться к пробуждению сознания)