It was just an example, one of many. In this particular case, when
json_decode encounters a piece of broken JSON it croaks, telling me what
went wrong. This is exactly the desired behavior; what is not desired is
the detail added by croak() itself. The error was in the data, I have no
need to know where in the code it was discovered. If I want to get rid of
it I have to employ a complicated and unwieldy regex pattern substitution
which is very fragile and expensive way to deal with such a common thing
as exception.
croak() is the default exception propagation mechanism for many Perl
module authors; it is natural to use croak() instead of die() in modules.
However unlike die(), croak() has somewhat fuzzy semantics: the module
author cannot always control the way a module is used; programmer who
calls module methods should always be in control.
For example, why existing Carp global variables like $Verbose are there?
Exactly for this purpose: when I call something that may possibly croak(),
I want to control how much information I will get without having to
interfere with called module logic.
This is exactly why I suggested to have a way to *lessen* croak() output,
as opposite to making it more verbose. In my opinion, this would bring
many benefits without actually breaking anything. After all, to use such a
feature I'd have to explicitly set the flag which implies that I know what
I'm doing.
Implementation of such a feature wouldn't be much of a burden, too. At
least, that seems easier than to petition all or almost all CPAN authors
to generate structured exception objects... Which are not ideal solution
either.
Regards,
Alex.
