Overheard at YAPC last night:
Person one: I can't find Try::Tiny exciting.
Person two: Isn't promoting that admitting that Perl 5's exception handling is broken?
(Perl 5.13.1 introduced improvements to Perl 5 exception handling. They
need more testing on existing code, but the Perl 5.14 release next year will
likely include them. The existence of Try::Tiny has directly
produced language improvements; in this case the cycle works.)
I like Try::Tiny; it simplifies exception handling in Perl 5.
Handling exceptions correctly (even in 5.12) is difficult. That's
primarily a syntax issue. You can handle exceptions
correctly—Perl 5 provides all of the tools necessary to do so—but
it's not simple to read or to write.
Similarly, runtime type reflection is difficult: ref is
unreliable and the standard hacks for abusing UNIVERSAL::isa are
far too often wrong.
Try::Tiny is nice because it offers good syntax which hides all of the internal complexity Perl 5 exposes. A world with T::T is better than a world without it.
Even so, Try::Tiny is only useful to people who know that it
exists, who can install it, and who make use of it pervasively.
Try::Tiny isn't useful for people who don't know it exists. In
other words, Try::Tiny isn't useful for novices. It
could be and it should be, but novices aren't going to hear
about it. (Some will, but how many novice Perl developers know about the CPAN?
How many novices have joined the Perl community sufficiently that they can
learn from the hard-won wisdom of Perl adepts? Vanishingly few, as they do not
remain novices for long.)
Here's the virtuous dilemma: isn't it nice to have a language with a working and well maintained extension mechanism? Isn't it nice to be able to modify our own languages in our own lexical scopes? Yet when our language modifications improve basic language features—instead of adding new language features—should we praise them as victories instead of acknowledging them for the patches and bugfixes that they are?
Yes, changing how exception handling works in Perl 5 now, especially if it requires semantic changes, may cause some pain. (It may also fix undiscovered bugs in existing programs, which is a virtue of its own.) Yet isn't the ability to modify the language for your own purposes sometimes akin to running a patched version of the language itself?
Yes, it's safer and more composable, and less permanent than running a patched binary, but still....
I admit it, I'm person 1. There's a reason why I said this though, and it's not that I don't care about mundane things like improving exception handling.
No offense to Yuval, and I have no reason to think there's anything wrong with the code in Try::Tiny. However, I stopped using Error.pm because the implementation -- using prototypes to make the sub refs look like built-in syntax -- caused subtle bugs and confused the hell out of newer perl coders. There's the failed return() calls, the missing final semi-colon bugs, and there used to be a bad memory leak, which is thankfully fixed in more recent perls. For these reasons, and a general desire to avoid code that looks like something other than what it is (those are subs, not just blocks), I dropped Error.pm.
Try::Tiny uses the same sub prototype trick as Error.pm. That's why it's hard for me to get excited about it. I'll nearly always give up nicer-looking code for code that's more obvious about what it's doing. I realize that's not a popular view in ANY dynamic language, but it's the thing I've chosen to optimize my perl code for.
The main reason I wrote Try::Tiny is because so many people simply did not know how to properly catch errors.
I got sick of explaining it on IRC and just coded up something which was entirely educational at first.
In that respect I don't think you are the target audience, that is people who are not well versed in the intricacies of Perl.
BTW, nitpicking: the return() thing is a non issue, it works the same as in eval { }. If anything TryCatch is the culrprit here for being incompatible ;-)
My biggest complaint is that try { ... }; without having loaded Try::Tiny is not a syntax error, but an indirect method call.
I speculate that Try::Tiny's relative success as a tool (as opposed to a lightning talk, what it started as) is owed to a number of factors which don't really apply to Error.pm. First, it's been 3 major releases (i think) since the leak has been plugged. Second, Error.pm (and other error modules) address way more than just $@ being odd, so they are harder to swallow. Third, the perl community has finally let go of the "subroutines slow" mentality that plagued it forever.
I must say I find this incredibly troubling.
I cannot fathom how denial of past failures is a viable long term plan for anything. It's one thing to have deficiencies, it's another thing entirely to refuse to fix them because they are embarrassing or bad for PR. That's only befitting of a government funded language.
Yeah, fair point about return/eval. It just feels like it should behave differently because that's what try/catch is like in most other languages.
I don't recall "subroutines are slow" being an issue, but things that look like blocks but behave like subs do seem confusing to me.
Congrats on a successful module!