I hopped on the bandwagon a while ago since I started using these two modules in my own projects so I could have real live try/catch blocks including MyError->throw(). As a bonus I get constraint matching on which catch block to execute.
Lots of people have pushing the Try::Tiny that Yuval put together and that's cool too, but I like my constraint matching. I have had several cases where it makes sense to do different things based on the type of exception I have received. And, I do enjoy having the lexicals put into my scope too.
For me, since I am already using MooseX::Declare which uses MooseX::Method::Signatures which uses Parse::Method::Signatures, it is a natural extension that my catch constraints be defined with the same syntax.
Recently though, I ran into a bug in TryCatch regarding certain scenarios with returns inside the try block. I banged my head against the wall for a day or so to no avail until I manned up and asked Ash what was going on. And much to my delighted surprise, it was already a reported issue and already fixed in a dev release on CPAN. I pulled it down and ran my tests and magically everything started working.
Anyhow, what prompted all of this was my work on POEx::WorkerPool. In my first go around, I wrapped a lot of the potential error spots in try/catch blocks but some of the handling was inconsistent, so I wanted to go back and rework a lot of that to be even more robust.
Now when errors occur, signals are handled properly inside of POE, and are reported via PubSub. For the most part, catastrophic errors are mitigated and reported instead of taking the whole enchilada down into some horrible state.
As soon as Ash does a non-dev release of TryCatch, I'll do another release of POEx::WorkerPool that includes this new found robustness.