On further thought, it seems to me that my "mileage" does indeed vary.
Rather I have a different notion of what the backtrace "trigger" is.
In my case, the longmess call occurs in a "utility" routine referred
to in $SIG{__DIE__} or $SIG{__WARN__} . I suspect that is a very common,
or perhaps even typical usage. I don't want my error report to the
user to mention the utility routine as it is not in fact the "trigger"
of interest and in fact could be confusing. By omitting this information,
longmess is doing exactly what I want. If the information about
the utility routine is indeed of interest, it can be added to the message.
That's what longmess is all about - letting you tailor the content, format,
and destination of the trace message.
So I think the longmess design does indeed make sense.
And, as I mentioned in my previous (Anonymous) comment,
would be repairable if it didn't.
So please restore the documentation of this function,
and get it out of this quasi-deprecated limbo.
Thanks,
-LenW
| [reply] |
Would it be possible for correct behavior to be
controlled by a non-default value of a variable?
Wouldn't that make it backwards compatible?
If that were done, could longmess be documented again?
It makes me nervous to use an undocumented feature that
"so far" is still available.
-LenW | [reply] |