Skip Menu |
 

This queue is for tickets about the Carp CPAN distribution.

Report information
The Basics
Id: 71095
Status: rejected
Priority: 0/
Queue: Carp

People
Owner: Nobody in particular
Requestors: nohuhu [...] nohuhu.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Suggestion: package global $NoLineInfo
Date: Tue, 20 Sep 2011 18:57:26 +0400
To: <bug-Carp [...] rt.cpan.org>
From: Alexander Tokarev <nohuhu [...] nohuhu.org>
Download (untitled) / with headers
text/plain 400b
It would be quite handy to have a way to make croak() less verbose. There are many situations where line and package information is not relevant, and something like this would be more clear and elegant: local $Carp::NoLineInfo = 1; my $data = eval { json_decode $json_text }; die "JSON parsing error: '$@'" if $@; ... instead of stripping $@ of line and package info post factum. Regards, Alex.
CC: undisclosed-recipients: ;
Subject: Re: [rt.cpan.org #71095] Suggestion: package global $NoLineInfo
Date: Wed, 21 Sep 2011 15:24:16 +0100
To: Alexander Tokarev via RT <bug-Carp [...] rt.cpan.org>
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 369b
Alexander Tokarev via RT wrote: Show quoted text
>It would be quite handy to have a way to make croak() less verbose.
It sounds like you don't want to use croak(), or you don't want json_decode() to use croak(). I suggest that you petition the author of your JSON module to generate structured exception objects or to provide an option controlling how it handles exceptions. -zefram
Subject: Re: [rt.cpan.org #71095] Suggestion: package global $NoLineInfo
Date: Wed, 21 Sep 2011 18:58:11 +0400
To: <bug-Carp [...] rt.cpan.org>
From: Alexander Tokarev <nohuhu [...] nohuhu.org>
Download (untitled) / with headers
text/plain 1.6k
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.
Download (untitled) / with headers
text/plain 763b
Adding $NoLineInfo would tend towards making Carp's exception format totally runtime-configurable, which is not what the module is for. It's also not a good way to configure exceptions that you're intending to propagate, because whether an error is in the code or in the data depends not only on what your program is doing but also which exception is being signalled: you only want to suppress line number information from (in your example) data-related exceptions in the JSON module. If an exception that you haven't thought about arises then it probably is because of a bug in your code and the line number would be useful. If you really really want to customise Carp's exception format beyond what it explicitly supports, you should monkey-patch it. -zefram


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.