You've proved quite a few times that chomp is not a good choice, in your case. Your case however does not represent everyone else's common uses. By your own definition here, a new line could exist and there could still be an error. In that case shouldn't your code be looking at the structure of the data it is attempting to load and relying on some other input other than the newline to mean your data is valid?
You've also mentioned chop several times but unless you (chop() eq $/ ) or die chop doesn't do you any more good than chomp did. I also believe it has been pointed out that your chop construct will actualy fail if $/ is more than one line, and in addition chomp isn't mean to remove record seperators, it is meant to portable remove a new line. As a feature chomp doesn't fail if there is no new line, but few of perls functions will die if they fail.
You attack everyone here as following groupthink and yet you can't seem to accept a new point of view yourself. I havn't seen anyone claim that chomp is ALWAYS the right choice, yet you claim it is ALWAYS the wrong choice. That flies in the face of the facts before you, chomp is quite often exactly what people want it to be, and when it isn't, then don't use it. Don't through it (and the people who use it) out simply because you have had a bad experience with it. Can it be misused? Of course it can, and is, but that realy doesn't mean it is always a bad choice.
If you want to use it as a measure of skill then fine, but be sure to make your requirements such that chomp alone is the wrong choice. Maybe something like "Write a script to parse a data file removing line endings and verify that each line ends with a terminator. Assume the files are provided on the command line and output them to STDOUT". That is my first attempt writing such a problem so please don't be too critical ;)
#!/usr/bin/perl
use strict;
use warnings;
while (<>) {
chomp or die "Record is missing terminating new line.";
print;
}
|