John Porter wrote:
> Glenn Linderman wrote:
> >
> > The idea of a _normal_ situation being considered exceptional is raised when the
> > code written inappropriately handles some of the normal return values.
>
> You would throw exceptions at the problem of bad coding practice.
Not the goal. There are, no doubt, many possible interpretations of why your example
line of code was bad, all couched in different justifications for using it.
> I think it's better to correct the bad coding practice.
That was actually my goal too.
> > > > $foo = "flabergasted";
> > > > substr($foo, index($foo, 'abc'), 20); # Returns undef
> >
> > contains errors. Clearly the current index, or even index modified to return
> > undef, doesn't produce the desired results. The inappropriate value of -1 (or
> > undef) passed as the 2nd parameter to substr will produce erroneous results.
>
> Right. But this is not so much an argument for making index throw, as for
> encouraging programmers to write good code, i.e.
>
> $foo = "flabergasted";
> if ( defined my $i = index($foo, 'abc') ) {
> substr( $foo, $i, 20 );
> }
> else {
> # do what you want with this condition.
> }
Clearly with the $foo = "flabergasted" ; line in place, the whole example could be
replaced with
substr ($foo, -1, 20 );
or even
undef;
So removing that line and allowing for variability in the possible values for $foo,
the question is whether the programmer so strongly believes that 'abc' will be found
that he wishes to return it and the next 17 characters, and take extreme risk with his
code if it is not found, or whether there is really a useful alternative action to be
done in the "normal" case that 'abc' is not found in $foo.
If the intention is that 'abc' is really expected to be found in all $foo, and is just
the demarcation of the next 17 useful characters, then your "better code" costs
several extra lines, and the exception which wouldn't be taken most of the time,
resulting in little additional cost or complexity, would allow the single line
solution you originally proposed, which is nice and concise for the case where not
finding 'abc' is unexpected.
Only you, of course, can supply the intentions behind your example, but by omitting
the "do what you want with this condition" part, you clearly left it up for grabs to
be interpreted as abnormal.
> The whole point, IMHO, is that index() should return a value which cannot
> be used as an index. -1 clearly does not meet this criterion.
I totally agree that having index return undef on failure to find the string would be
an improvement to index. Then in could be wrapped by Fatal.pm, or Throw.pm, etc., and
we could all have and eat our cake.
--
Glenn
=====
Even if you're on the right track,
you'll get run over if you just sit there.
-- Will Rogers
_______________________________________________
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
