develooper Front page | perl.perl5.porters | Postings from November 2000

Re: Plan to try again with Carp

Thread Previous | Thread Next
From:
Hugo
Date:
November 26, 2000 17:08
Subject:
Re: Plan to try again with Carp
Message ID:
200011270211.CAA15168@crypt.compulink.co.uk
In <LAW2-F160VrDs9aAOPp00003882@hotmail.com>, "Ben Tilly" writes:
:Hugo wrote:
:>
:>In <LAW2-F99Wr81nn9RQAO00003271@hotmail.com>, "Ben Tilly" writes:
:>:Feedback?  Comments?
:>
:>It isn't clear to me why you want to kill $Carp::CarpLevel, though
:>I read your email through a couple of times to try and understand
:>this. I regularly use the moral equivalent of:
:>   local $Carp::CarpLevel = $Carp::CarpLevel + 1;
:>.. in diagnostic functions.
:
:Well there are two places that it exists.  I think that
:both are bad.  First of all for short messages it
:results in simply confusing behaviour:

I agree it is confusing - I'd never used it that way, so never
encountered the confusion. I don't understand why it doesn't do
exactly the same as longmess: print the diagnostic as if it had
been invoked by caller($CarpLevel).

:The other place it shows up is in long messages.  There
:it actually does do something moderately useful.  It
:edits call levels out.  If (as a debugger might) you
:have kept track of call levels, then you can use it to
:edit yourself out of the messages.  Now suppose that
:you want to guarantee that Exporter is supposed to
:not show up if someone sets $Carp::Verbose to a true
:value.  Now you have to go through how much work to
:figure out the correct $Carp::CarpLevel to set?

Add:
  local $Carp::CarpLevel = $Carp::CarpLevel + 1;
in each function you want to edit out. There, that was easy. :)

:Since that is apparently the point of having it, I would
:prefer to set up a simpler API to get that effect.

The effect I want is exactly the longmess effect: edit out a
single caller() level. I may well do that within the same package
that the error should really be reported from, so it is not
sufficient for the purpose to be able to specify only packages
to be edited out.

:If people think that I am being too extreme, then
:please tell me what behaviour you think it should
:have and we can implement that.  But I will be
:shocked and amazed if people can some up with good
:a priori reasons why the current behaviour makes
:sense or is maintainable.  Certainly the places where
:I have seen people try to use it have usually led to
:bugs!

I've never had a use for the shortmess() behaviour, but that may
just be me. Maybe we need a %IgnorePackage as you suggest, but
I hope we won't lose the existing $CarpLevel effect for longmess(),
and I'd quite like to see such an effect available for shortmess(),
preferably using the same mechanism.

As a sidenote, I have had problems in the past using packages that
carped their errors up a level even though they were generating the
error themselves. This can make debugging real difficult. However,
when this is done by means of a localised $CarpLevel change it is
easy to override it remotely with a
  local $Carp::CarpLevel = $Carp::CarpLevel - 1;
.. and I suspect %IgnorePackage would not permit so easy a remedy.

Hugo

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About