Update perlfunc.pod to document die newline workarounds
Else the user cannot find where the program died!
Welcome to enhance my patch.
What does a user care where a program died?
Because s/he might have 50 files, each with 50 die statements, and finding which one died would be a nightmare.
It's only a nightmare to find which die is which if your die messages don't contain unique/useful messages.
You really have two problems bumping up against each other here and it mostly goes away if, as a point of order, you include a label before you Dumper something to an output. Pick something unique so you can git grep for it.
I usually sub-class which ever logger the project uses with a labeled_dump method that dies if it doesn't get a label.
$app->log->labelled_dump( customer_credit_carrds => \@cards );
# Tue 27 [9203] request=b4dc0ffee [debug] customer_credit_cards [{type => amex....
Even in a single-file script using Data::Dumper directly is a bit of a pest, so I end up wrapping it in a similar sub (adding time, setting formatting etc)
The very very very very main source of problems, is the person way back one who thought it would be smart to make things act different depending on a final new line.
It might have seen like a cool idea way back when. But sure enough ...
Also one can I just use $. In here-documents, and then getting the file name is a big drag too.
So okay you guys are welcome to put your ideas into the die documentation too.
-
Most programs don't include line numbers when showing error messages to users... Try
ls --nonsenseordocker evengreenorhalt --hammerzeit -
dieis how one raises exceptions, and you don't want line numbers in the string your callers get when catching and checking your exception. -
If you want to blame the caller for an exception (say when they pass invalid arguments) you need to be able to
diewithout the site where you calldiebeing in the message (like carp) -
Changing this behaviour breaks compat with existing code.
Maybe you can write a perlcritic role to prevent this being done on accident if your own code?
I don't want to change the code.
But workarounds should be documented for when we want to keep getting the line numbers, despite having a newline in our back pocket.
Yeah I don't think this is a good idea either
Yeah I don't think this is a good idea either
There has been no further conversation in this ticket in five months. Closing.