You're assuming that the only reason to catch an error is to try to fix it. There are lots of other reasons, like ignoring it, changing the error message for a different audience, etc.

Actually, I didn't make that assumtion. In the next para down I said:

If they are further back up the call hierarchy, all they can do is report the error (or ignore it), and they don't need to parse the error message, it already contains the relevant information.

I didn't mention the "switch error message" explicitly, and I won't bore you with how easy that is to do with eval and die.

Though I could make an extensive case for NOT dumbing down error messages for "the user". If the error is important enough to report, it's important enough to ensure that when the user reports the error back to the developers, it contains enough information to allow you to do something about it. Without having to ask the user to toggle some config or command line switches and then try and reproduce the error before you can begin to address it.

But that's an argument for another time.

And the really nice thing about Exception::Class is that if you don't care about all the extra goodies it provides, then just ignore it an treat it like a string and leave the rest of us alone.

I'd ask you to re-read all my posts in this thread, but you won't, so you'll have to take my word for this.

The bit that everyone seems to have missed, is that I have never once said that anyone should not use Exception::Class. Never, not once.

My original thrust was, that having a diagnostic tool with the default set to flag all uses of the block eval & die exception handling mechanism, as "verbotten", is stupid. And that the justifictions cited in support of that were--and are--bogus.

I followed that with the assertions--that I maintain--that :

1. Exception::Class doesn't avoid string comparisons, it just moves them elsewhere;
2. That the implementation of E::C means that the number of error vectors due to typos, is actually greater than with eval & die;

   This because the number of different places where the name of the exception has to be supplied, as a string, which are therefore not checked or cross-referenced in any way by the compiler.

   And because package names are stored as hash (stash) keys, they are also not subject to compile-time checks. (strict & warnings).

Indeed, I have, do, and will continue to prefer exceptions to error returns for most code in most languages I use, including Perl. And having discovered Try::Tiny, I'll probably use that in preference to eval & die in future. Where warranted.

I seriously doubt that I will ever use or recommend E::C--because of the way it bypasses compile time check through the use of strings--but I would never for one instant try and stop anyone else from using it. Though I might again point out its weaknesses to newcomers to that module. Beyond that, it is up to them.

So, I'll hope you'll see that I'm not the one being unreasonable here. I'd really like to move beyond the he said/she said stage and get to the point where we could do the pragmatic thing of comparing the failure vectors of concrete code. I've invited same, without response.

Apparently, there are some 60 modules out of the 18,000+ on CPAN that use E::C, but try as hard as I might, I have still to find a simple, complete, worked example of its use. The synopsis snippets don't form a working example, and the (lack of) diagnostics mean that I've failed to get my attempt, posted near the top of this thread, to work.

I'm not a newbie, and I have a track record of getting difficult stuff to work, but so far it has defeated me. The lack of any working examples posted in response to my request make me conclude that perhaps others have similar problems.