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.)
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:
unreliable and the standard hacks for abusing
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.
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
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....