А какие у этого try практические плюсы перед eval?

Джава-господа не писаются с порога

С eval можно выстрелить себе в ногу. С помощью любых перловых try/catch тоже, но например, последствия локализации $@ обычно нивелируются.

Как и у всех правильно сделанных конструкций такого типа - правильное разматывание стека.

Если при выходе из евал вызывается деструктор, внутри которого есть евал, то значение $@ переписывается

Джава-господам должен заходить пхп, там эта часть один в один

Да, но ядерный try/catch тоже чудной, что печалит

Вы всему верите, что вам говорят? ) perl -e 'eval { die 5 }; print "`$@`\n"; eval {6}; print "`$@`\n";' `5 at -e line 1. ` ``

Стикер

Что с eval нельзя выстрелить себе в ногу. Существует распространённое заблуждение, что удачно завершившийся eval не сбрасывает $@. Приведённый однострочник это опровергает

наоборот. я же описал как

Эээ... Это где это такое распространено и по какой логике? Проверка $@ сразу после eval - это основное её использование и оно бы не работало если бы всё было согласно "заблуждению".

Просто люди зачем-то модули вроде Try::Tiny используют и утверждают, что eval "плохо работает" )

потому что у того в доке описаны всякие corner cases, и он удобнее

Мне вот не удобно подниматься в начало файла и там прописывать use Try::Tiny и затем возвращаться. Хотя я и использую для этого закладки. Ещё он зачем-то подменяет $@ на $_. А если у меня в $_ уже есть значение, то его придётся перекладывать в какую-то переменную? Или под "удобно" имеется ввиду не удобство программирования, а нечто иное? )

Если у тебя в $_ есть значение, то ты уже немношко не прав

map { eval { 1/$_ } } 0..3

Ты имеешь ввиду, что все перловики немножко не правы, что программируют на языке в котором есть $_ ? ;)

Не, $_ иногда полезна. Но... если есть возможность, лучше без.

вы еще не используете тайд local $_ ? тогда мы идём к вам кипятить вас!

а с началом файла ты нас просто троллишь пьяным пятничным вечером, признайся :)

use Try::Tiny; my @floats; for my $integer (0.. 3) { . push @floats, try { . return 1/$integer; . } catch { . return; . } } Это правильнее?

При чём тут local? Вот как переписать этот пример с local, без $x? map { my $x=$_; try { 1/$x } catch { say "$x $_" } } 0..3

это был тонкий намёк, что AnyEvent отучает от $_ или хотя бы заставляет локализовывать его :)

кстати, return в Try::Tiny не работает :)

Перл много где позволяет изъебнуться. Но в большинстве ситуаций наверное не стоит

Coro лучше AnyEvent, разве нет? )

try { map { 1/$_ } 0..3; } catch { say "caught $_" }

не всё корофицировали :)

Гм. Вместо счётчика caught

Illegal division by zero at -e line 2 вполне достаточно для дебага :)

Всё что энифицировали, то всё и корофицировали, потому что в Coro есть rouse_cb/rouse_wait, для превращения выражений эниэвент в коро

прям всё настолько просто и без подводных граблей?

А на каком шаге произошла ошибка?

Стикер

А если деление в недрах библиотечной функции происходит, а в ней делается минус 3 счётчику, например?

c библиотечной у тебя и в случае eval {} такие же проблемы

Да. Ещё распространённая задача какие-то глобальные переменные переключать с переключением волокон. Для этого есть обработчики событий выхода и входа из/в произвольное волокно

map { . my $x=$_; . try { fn_in_lib($x) } . catch { say "$x $_" } } 0..3 map { . eval { fn_in_lib($_) }; . say "$_ $@" if $@; } 0..3 где это?

где-то в жопе, если fn_in_lib сама использует $_ =)

AnyEvent всё равно остаётся, как более низкоуровневый инструмент.

perl <- go <- c <- asm <- машинные коды <- плис <- микросхемы <- счёты