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

Re: [ID 20000330.052] Use of uninitialized value in concatenation (.)

Thread Previous | Thread Next
Joseph N. Hall
March 30, 2000 21:30
Re: [ID 20000330.052] Use of uninitialized value in concatenation (.)
Message ID:
> On Thu, Mar 30, 2000 at 08:12:12PM -0800, William R. Ward wrote:
> > Simply saying "use of uninitialized variable in line xxx" is fine, but
> > once you start trying to tell the user what operator went wrong, you
> > have to be accurate when you do so.
> I agree.  The same correction was made for the comparison operators;
> originally the warning did not distinguish between numeric and string
> comparison operators.  The warning should accurately reflect the code as
> written.

I don't think there's anything "dumb" about a user potentially (or
in reality) being confused by a message that describes a concatenation
operator but refers to a line containing only a double-quoted string.
It looks more like Perl is the dummy here.

Let's consider the notion that users should shoulder responsibility for
deciphering "best effort" messages from the compiler.  Personally, I
find that repugnant.  Bogus error messages and, to a lesser extent,
poor error recovery (leading to a cascade of seriously bogus error 
messages) are the product of poor design, poor engineering, and/or
poor programming.  It is possible for a compiler to generate accurate,
appropriate error messages.  It's just not all that common nowadays.

During the ten or so years when I was writing interpreters and compilers
off and on as part of my work, I took pride in my attempts (mostly
successful) to have my software generate sensible parse and run-time
error messages.  Because users often interacted with me directly, and
because I generally worked as a contractor, I never had the option of 
telling my users "Well, if you don't know what my software is telling
you, it's not my problem.  You're just stupid."  I mean, we've all 
had idiot users, but since when is a software tool supposed to be, on
its face, an intellectual challenge for its users?  So when users came
to me and told me, "Hey, I have no idea what this error is," I tried
to make it clearer.  Generating error messages that even an idiot
can (potentially) understand is a source of pride, not shame, for me.

I'm dumbfounded that anyone would take a position that not only
accepts Perl's sometimes (often?) poor error handling, but in fact
advocates it, as though Perl should be some kind of continually
stimulating intellectual puzzle.  I'm even more amazed when the poor
messages in question come from the warnings feature, which is
ostensibly present in large part for the benefit of the less clueful.
Is the point here that Perl should always be confusing, even if you
activate the features that are supposed to make it safer and

I think it's clear on its face that "Use of uninitialized value 
in concatenation (.)" as described in the original message is
inappropriate behavior.  Dragging "it's the same ops" into the
issue is silly.  That's the reason for the misbehavior, of course,
but it doesn't excuse the poor message.

I've never thought Perl should be a language that deliberately
gets in your way, like the school bully crowding the doorway, 
asking for your lunch money.  Or in this case, asking you to find
the hidden dot operator.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About