Don't Core Your Workarounds

Exception handling in Perl 5 seems easy, until you realize all of the things that could possibly go wrong between the time your eval BLOCK exits and you check the global variable $@. Fortunately, Try::Tiny hides most of the difficult details from you, so you can concentrate on writing good exception handlers without worrying about all of the special cases that may eventually confuse and concern you.

It was inevitable to see a suggestion to put Try::Tiny in the core, and the resulting discussion of conflicting goals and motivations and reasons to remove things from the core and suggestions of other things to put in the core was even more inevitable. (If you've read one thread like this before, you've read one too many.)

Yuval Kogman, the author of Try::Tiny responded the other day, saying that Try::Tiny is a band-aid, not a solution.

Here's a design principle.

Exception handling in Perl 5 is difficult to use with complete safety and correctness. You have to beware of a few strange edge conditions that, in most software, never occur. When they do occur, they're strange and difficult because of the semantics of how scopes and exceptions and destruction and call-graph unwinding occur in Perl 5.

Making Try::Tiny a core module—and recommending it as the core-approved way of handling exceptions in Perl 5—enshrines that workaround as well as the flaws of implementation around which it works. The module exists as an alternative to a proper fix at the language and implementation levels. It's a patch. It's a workaround. It's not a controversial extension to the language that some people may want and others don't. Instead, it's a makeshift that offers more safety and correctness and abstractions around those relatively unknown idioms to help people write better programs.

In the same way, signatures is a workaround for the lack of a feature in Perl 5 as much as MooseX::Declare is a workaround for the lack of succinct boilerplate-reducing features in Perl 5.

Making extensions possible doesn't relieve language designers and implementors from the responsibility of providing necessary features and abstractions.

Devel::Declare is, in general, a good thing because it allows experimentation with language features and ideas that may be useful in the core eventually, or may be useful in specific domains, or may be unsuccessful, but at least provide that data. Safety and ease of experimentation help develop communities of invention and evolution.

... but you have to recognize workarounds for what they are. Next time, I'll explain the practical consequences of this tension.