What's the big deal.

Here is an example. You are calling cleaner in some sub that is not always called in the CGI. You will get a 500 when you do and won't know about it until it happens because it is a runtime not compile time error. This script will crash 50% of the time:

sub cleaner { $_[0] =~ s/foo/bar/; }

if  ( rand > 0.5 ) { cleaner('foo') }

__DATA__
Modification of a read-only value attempted at script line 1. # someti
+mes
[download]

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

<sarcasm>
Using die is bad practice. Here is an example. If you use it you will get a 500 when you do and won't know about it until it happens because it is a runtime not compile time error. This script will crash 50% of the time:

if ( rand > 0.5 ) { die "foo" }
[download]

</sarcasm>

Seriously what is your point? You can cause runtime errors with many Perl constructs and it doesn't necessary mean that using them is a bad practice. OUT parameters is a powerful language feature when used wisely.

--
Ilya Martynov, ilya@iponweb.net
CTO IPonWEB (UK) Ltd
Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net
Personal website - http://martynov.org

I never use die in CGI. I use a custom die_nice() routine which you will see dozens of references to if you do a Super Search for 'tachyon die_nice'. This is not a CGI, this is a demo snippet to illustrate a point so using die is perfectly appropriate. Your sarcasm is wasted.

Presenting OUT parameters to someone (obviously very inexperienced) with a "this is an OK way to do it" and not mentioning the problem I noted is sub optimal IMHO. You know that they will probably use the code verbatim.....

If you use OUT parameters much you will get caught passing constants to them. These bugs may not immediatly be obvious. You avoid this problem by not using them. I would be interested to see a good example of where they are a powerful and indespensible language feature given that you can easily pass references to and from subs.

If you are doing a code review which is easer to understand without looking at cleaner()

# for sub cleaner { my $var = shift; $var =~ s/foo/bar/; $var }
my $var = cleaner($var);
# then maybe lines later...
print $var
# or in a single line
print cleaner($var);

# or this if you have sub cleaner { $_[0] =~ s/foo/bar/ }
cleaner($var);
# then maybe lines later...
print $var;
# and you can't
print cleaner($var)
# unless you have sub cleaner { $_[0] =~ s/foo/bar; $_[0] }
[download]

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

It may crash 50% of the time, but it only takes one crash to alert the programmer to her misuse of the function. It's incumbent on the programmer to know how to call the API correctly. Especially if it's her own.
The simple fact is that perl is a dynamic language, and provides many essential features that can only be fully realized at "run time". That means run time errors (i.e. exceptions) are going to happen, you can count on it, and if you're a half-way careful programmer, you're going to prepare for them to happen. If the fact that your program is a CGI makes this preparation a little more difficult, well then, tough. Deal with it. Trap $SIG{__DIE__} if you have to. But don't forbid run-time exceptions, because you can't anyway. What does   $foo->bar; do? There are several possibilities, including Can't locate object method "bar", and none of them can be caught at compile time. That's just the nature of the beast (Perl).

jdporter
...porque es dificil estar guapo y blanco.