[29570] in Perl-Users-Digest
Perl-Users Digest, Issue: 814 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Sep 1 11:09:44 2007
Date: Sat, 1 Sep 2007 08:09:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 1 Sep 2007 Volume: 11 Number: 814
Today's topics:
Re: Compare Dates <No_4@dsl.pipex.com>
Re: get memory percent usage info <s.denaxas@gmail.com>
Re: Important Research Project <edgrsprj@ix.netcom.com>
Re: Important Research Project <george.sakkis@gmail.com>
Re: Important Research Project (Kenny McCormack)
new CPAN modules on Sat Sep 1 2007 (Randal Schwartz)
Why use die? <bill@ts1000.us>
Re: Why use die? <wahab-mail@gmx.de>
Re: Why use die? <hjp-usenet2@hjp.at>
Re: Why use die? <anno4000@radom.zrz.tu-berlin.de>
Re: Why use die? <stoupa@practisoft.cz>
Re: Why use die? <1usa@llenroc.ude.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 01 Sep 2007 14:56:05 +0100
From: Big and Blue <No_4@dsl.pipex.com>
Subject: Re: Compare Dates
Message-Id: <34qdnQeq0vnn8kTbRVnyjQA@pipex.net>
Ben Bullock wrote:
>
> Change the year of all your dates to be the same arbitrary year (make it a
> leap year), then use the Day_of_Year function from
> Date::Calc to get the day of the year (see
> http://www.unix.org.ua/orelly/perl/cookbook/ch03_07.htm), then compare the
> numbers.
Or just use the month and day while assuming all months have 32 days.
sub date_index {
(my ($m, $d)) = $_[0] =~ /^\d{4}-(\d{2})-(\d{2})$/;
return ($m<<5) + $d;
}
then just compare the results from date_index calls.
--
Just because I've written it doesn't mean that
either you or I have to believe it.
------------------------------
Date: Sat, 01 Sep 2007 12:22:13 -0000
From: Spiros Denaxas <s.denaxas@gmail.com>
Subject: Re: get memory percent usage info
Message-Id: <1188649333.489627.260920@o80g2000hse.googlegroups.com>
On Aug 31, 7:09 pm, Ken <KenP...@gmail.com> wrote:
> hi,
>
> how to get a Perl program memory percent usage information within the
> program itself, so that I can write that info to the stand out?
Hi,
If you are after the memory size of individual data structures, you
can use Devel::Size , found at http://search.cpan.org/~tels/Devel-Size-0.69/lib/Devel/Size.pm
. If however you are after the memory footprint of the entire Perl
script, you would probably want to use Proc::ProccessTable, found at
http://search.cpan.org/~durist/Proc-ProcessTable-0.41/ProcessTable.pm.
This effective will return you a UNIX process table with all the
relevant information. You could locate your script easily by searching
for the PID in the table ( $$ ).
Hope this helps,
Spiros
------------------------------
Date: Fri, 31 Aug 2007 22:13:27 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: Important Research Project
Message-Id: <13dhm7uec5sp855@corp.supernews.com>
"E.D.G." <edgrsprj@ix.netcom.com> wrote in message
news:13ddcvm1bsu3s94@corp.supernews.com...
> Important Research Project (Related to computer programming)
>
> Posted by E.D.G. on August 30, 2007 edgrsprj@ix.netcom.com
This effort was not successful. And I am returning to trying to slowly
make progress with the computer program I have been developing.
I was hoping that there might be some people who had Perl chart and .exe
generation programs running on their own computer who could say, "Here is
how to merge them with Perl; here is how to use them; this is what they will
do, etc." Or, I was hoping that someone would respond and say that although
they are using Fortran or Basic etc. instead of Perl, they would be
interested in getting a copy of Perl running, determine how to get those
routines running, and then pass along the information. That would have
saved some time.
I work on these projects all the time. And it has been my experience
that the world of science does not have the type of organized structure at
this time to enable people to easily obtain that type of assistance. I have
established an organization which will hopefully help with that problem. It
might be going public at a Web site some time in the next year.
There were some questions regarding the computer program I discussed. This
is what it does:
It provides researchers with the a certain amount of ability to
determine if different events are somehow linked with one another. For
example, it can be used to compare two or more earthquakes, earthquakes and
electromagnetic pulses, tornados and electromagnetic pulses, and even
earthquakes and tornados etc.
It makes it possible for people to study events taking place deep in the
Earth by evaluating electromagnetic pulse data associated with those events.
Under the right conditions it can be used to forecast earthquakes. That is
the reason it was developed in the first place. You can see the type of
data it generates at the following Web page:
http://www.freewebz.com/eq-forecasting/Data.html
The plan is that when it has chart and standalone .exe program file
generation capabilities, program copies will be circulated within the
earthquake forecasting community in the People's Republic of China. It was
discussed in detail there at a scientific conference in December of 2003.
At that time it was too complex for widespread use.
After the chart feature becomes operational etc. I am also planning to
contact U.S. government officials to see if one or more lectures can be
organized regarding the basic technology and theories, and the program's
capabilities.
These are personal opinions.
------------------------------
Date: Sat, 01 Sep 2007 14:28:34 -0000
From: George Sakkis <george.sakkis@gmail.com>
Subject: Re: Important Research Project
Message-Id: <1188656914.179330.167630@r29g2000hsg.googlegroups.com>
On Sep 1, 7:13 am, "E.D.G." <edgrs...@ix.netcom.com> wrote:
> "E.D.G." <edgrs...@ix.netcom.com> wrote in message
>
> news:13ddcvm1bsu3s94@corp.supernews.com...
>
> > Important Research Project (Related to computer programming)
>
> > Posted by E.D.G. on August 30, 2007 edgrs...@ix.netcom.com
>
> This effort was not successful.
Shocking, isn't it ?
> And I am returning to trying to slowly
> make progress with the computer program I have been developing.
You might have more luck if you read http://catb.org/~esr/faqs/smart-questions.html#forum
before asking for help again.
------------------------------
Date: Sat, 1 Sep 2007 14:49:14 +0000 (UTC)
From: gazelle@xmission.xmission.com (Kenny McCormack)
Subject: Re: Important Research Project
Message-Id: <fbbu5a$a8v$1@news.xmission.com>
In article <lnsl60o492.fsf@nuthaus.mib.org>,
Keith Thompson <kst-u@mib.org> wrote:
>"E.D.G." <edgrsprj@ix.netcom.com> writes:
>> "CBFalconer" <cbfalconer@yahoo.com> wrote in message
>> news:46D6CA0E.E66ED5C8@yahoo.com...
>>> "E.D.G." wrote:
>>
>>> Where is Perl described in the C standard? This seems rather OT.
>>
>> It has been my experience that a person who is an expert with one computer
>> language can usually do reasonably well when working with other languages.
>> I am trying to find some people who can assist with getting a Perl program
>> running. It would probably be easier for expert programmers in any language
>> to help with this type of work compared with people such as myself who are
>> not experts in any programming language.
>
>CBFalconer's point is that this newsgroup (comp.lang.c, where he and I
>are both reading this) is for discussion of the C programming
>language. If you want to discuss something other than C, please find
>another forum. Massive cross-posts like this are rarely appropriate.
IOW (for the OP and for the various readers in all these groups):
The rod up Keith's butt has a rod up its butt.
Note, incidentally, that this thread is yet the latest occurrence of a
phenomenon that I've observed many times in the past, and have
described here in clc on more than a few occasions. That is, somebody
starts a thread, posted to several different groups, in the hope of
getting help from at least one of them. The thread is pretty much
on-topic for most of the groups, primarily because the keepers of most
of the groups do not have rods up their butts.
However, and this is the big however, one of the groups listed just
happens to be clc, where rod-filled butts are the norm. The result is
that all of the responses come from clc (including, of course, this one)
and, as we see, it's all topicality BS, and nobody ever ends up
discussing the original subject. Really a pity, that.
------------------------------
Date: Sat, 1 Sep 2007 04:42:13 GMT
From: merlyn@stonehenge.com (Randal Schwartz)
Subject: new CPAN modules on Sat Sep 1 2007
Message-Id: <JnoAED.JK4@zorch.sf-bay.org>
The following modules have recently been added to or updated in the
Comprehensive Perl Archive Network (CPAN). You can install them using the
instructions in the 'perlmodinstall' page included with your Perl
distribution.
Business-ISBN-Data-1.15
http://search.cpan.org/~bdfoy/Business-ISBN-Data-1.15/
data pack for Business::ISBN
----
Class-Simple-0.12
http://search.cpan.org/~sullivan/Class-Simple-0.12/
Simple Object-Oriented Base Class
----
Egg-Plugin-IxHash-2.02
http://search.cpan.org/~lushe/Egg-Plugin-IxHash-2.02/
Tie::Hash::Indexed for Egg plugin.
----
GD-Graph-smoothlines-1.2
http://search.cpan.org/~andrei/GD-Graph-smoothlines-1.2/
----
Games-Tournament-Swiss-0.06
http://search.cpan.org/~drbean/Games-Tournament-Swiss-0.06/
FIDE Swiss Same-Rank Contestant Pairing
----
JavaScript-Writer-0.0.6
http://search.cpan.org/~gugod/JavaScript-Writer-0.0.6/
JavaScript code generation from Perl.
----
Logfile-EPrints-1.12
http://search.cpan.org/~timbrody/Logfile-EPrints-1.12/
Parse Apache logs from GNU EPrints
----
MIME-tools-5.420_02
http://search.cpan.org/~doneill/MIME-tools-5.420_02/
----
Nagios-Plugin-0.17
http://search.cpan.org/~tonvoon/Nagios-Plugin-0.17/
a family of perl modules to streamline writing Nagios plugins
----
Net-POP3-PerMsgHandler-0.01
http://search.cpan.org/~bokutin/Net-POP3-PerMsgHandler-0.01/
subroutine for per message from POP3 server
----
Net-TacacsPlus-1.03
http://search.cpan.org/~jkutej/Net-TacacsPlus-1.03/
Tacacs+ library
----
OIS-0.02
http://search.cpan.org/~slanning/OIS-0.02/
Perl binding for the OIS C++ input framework
----
Ogre-0.20
http://search.cpan.org/~slanning/Ogre-0.20/
Perl binding for the OGRE C++ graphics library
----
OpenGL-Image-1.02
http://search.cpan.org/~bfree/OpenGL-Image-1.02/
copyright 2007 Graphcomp - ALL RIGHTS RESERVED Author: Bob "grafman" Free - grafman@graphcomp.com Contributor: Geoff Broadwell
----
POE-Filter-Stomp-0.01
http://search.cpan.org/~kesteb/POE-Filter-Stomp-0.01/
Perl extension for the POE Environment
----
Term-Menus-1.24
http://search.cpan.org/~reedfish/Term-Menus-1.24/
Create Powerful Terminal, Console and CMD Enviroment Menus
----
Tie-RefHash-Weak-0.03
http://search.cpan.org/~nuffin/Tie-RefHash-Weak-0.03/
A Tie::RefHash subclass with weakened references in the keys.
----
Tripletail-0.32
http://search.cpan.org/~hio/Tripletail-0.32/
Tripletail, Framework for Japanese Web Application
----
Unicode-Japanese-0.41
http://search.cpan.org/~hio/Unicode-Japanese-0.41/
Japanese Character Encoding Handler 1
----
VCI-0.0.2
http://search.cpan.org/~mkanat/VCI-0.0.2/
A generic interface for interacting with various version-control systems.
----
VCI-0.0.3
http://search.cpan.org/~mkanat/VCI-0.0.3/
A generic interface for interacting with various version-control systems.
----
VCI-0.1.0_1
http://search.cpan.org/~mkanat/VCI-0.1.0_1/
A generic interface for interacting with various version-control systems.
----
Win32-SysTray-0.11
http://search.cpan.org/~mahnkong/Win32-SysTray-0.11/
If you're an author of one of these modules, please submit a detailed
announcement to comp.lang.perl.announce, and we'll pass it along.
This message was generated by a Perl program described in my Linux
Magazine column, which can be found on-line (along with more than
200 other freely available past column articles) at
http://www.stonehenge.com/merlyn/LinuxMag/col82.html
print "Just another Perl hacker," # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
------------------------------
Date: Sat, 01 Sep 2007 03:43:51 -0700
From: Bill H <bill@ts1000.us>
Subject: Why use die?
Message-Id: <1188643431.621334.88240@57g2000hsv.googlegroups.com>
Just to preface the following so I don't get the "daily WTF" or
comments on code, I am not a "perl guru", I write code everyday in
perl, and though good at it, I will be the 1st to admit I don't know
everything.
I see examples like this in many programs, where you try to open a
file for write and you have a "die" statement after it:
open(TMP, '>'.$file) or die "Can't create file";
My question is, why would you use the "die" statement, ESPECIALLY in
the context of handling web based requests?
If you are controlling all of the inputs, filename, permissions, etc
and using flock, what is the need for a "die" statement?
It is not accomplishing anything, other than telling you that it could
not open the file, but again, if you control all the parameters then
it should be able to open the file everytime. If not, then it would
seem that the programmer did not anticipate everything that could stop
his program from working as expected.
Also, when perl is used as web based program, the die "some text"
isn't going to do anything except trigger a Server Error because you
do not have it in an HTML wrapper, unless you are using Carp, or it is
putting it in some log for later viewing (or I could be off on this,
if so let me know). Again, in the context of a web based program, the
die "some text", if shown to a visitor in a browser, is not going to
help the programmer, and may just help someone figure out how to hack
your program (especially if you are showing directory structures (ex:
die "Could not write $file /home/sites/www.domain.com/users/
webmaster")
It would seem more logical to have some error recovery routine instead
of a simple die. Somethig like:
open(TMP, '>'.$file) or try &errorHandlingRoutine;
Where if there was a failure it would execute the
&errorHandlingRoutine to attempt to fix the problem and then restart
the same line. The &errorHandlingRoutine could then "die" if it
couldn't fix it.
The perldocs say that you can have die almost do as I suggested, but
you can not return to the same line to try again.
Now knowing perl and the millions of module available out there,
something similar probably exists, but, if it does I have not seen
it.
Bill H
------------------------------
Date: Sat, 01 Sep 2007 14:33:37 +0200
From: Mirco Wahab <wahab-mail@gmx.de>
Subject: Re: Why use die?
Message-Id: <fbbmj1$jlg$1@mlucom4.urz.uni-halle.de>
Bill H wrote:
> I see examples like this in many programs, where you try to open a
> file for write and you have a "die" statement after it:
> open(TMP, '>'.$file) or die "Can't create file";
> My question is, why would you use the "die" statement, ESPECIALLY in
> the context of handling web based requests?
Exception handling is imho never trivial, in any language.
If the application logic is simple, if there's no
alternative to an "opened temp file", you have to
shut down the application. Why would you implement
exception handling if you don't have to?
Otherwise, there are quite a few ways in
Perl to do exception handling, also in
CGI- or mod_perl context.
Here are some thoughts on this topic
by somebody (which I found on the web):
http://axkit.org/docs/presentations/tpc2001/exceptions.axp/a.pdf
Do exception handling - if you have to,
don't do it, if you don't ...
Regards
M.
------------------------------
Date: Sat, 1 Sep 2007 14:42:13 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Why use die?
Message-Id: <slrnfdinh6.5d7.hjp-usenet2@zeno.hjp.at>
On 2007-09-01 10:43, Bill H <bill@ts1000.us> wrote:
> Just to preface the following so I don't get the "daily WTF" or
> comments on code, I am not a "perl guru", I write code everyday in
> perl, and though good at it, I will be the 1st to admit I don't know
> everything.
>
> I see examples like this in many programs, where you try to open a
> file for write and you have a "die" statement after it:
>
> open(TMP, '>'.$file) or die "Can't create file";
>
> My question is, why would you use the "die" statement, ESPECIALLY in
> the context of handling web based requests?
>
> If you are controlling all of the inputs, filename, permissions, etc
> and using flock, what is the need for a "die" statement?
You are never controlling everything. The file creation could fail
because the disk is full, because you've used too many file descriptors,
because the file server has just crashed and for a plethora of of other
reasons.
> It is not accomplishing anything, other than telling you that it could
> not open the file,
That's why it is good practice write
or die "Can't create $file: $!"
instead. Then you know which file you couldn't create and why (you might
also want to add a bit of context, so that you know where in your
program you tried to create that file and why).
> but again, if you control all the parameters then it should be able to
> open the file everytime. If not, then it would seem that the
> programmer did not anticipate everything that could stop his program
> from working as expected.
Even if I anticipate everything I may not be able to do anything about
it. Or it may not be worth the hassle.
> Also, when perl is used as web based program, the die "some text"
> isn't going to do anything except trigger a Server Error because you
> do not have it in an HTML wrapper, unless you are using Carp, or it is
> putting it in some log for later viewing (or I could be off on this,
> if so let me know).
Yes, putting the error message into the log is probably what you want to
do in a web-based program, so that the programmer can later eximine the
log and find out what went wrong. Showing the message to the user is
often not very useful, since even if they care to report the error, they
will only report something like "it didn't work. No I don't remember the
message. I just closed the internet".
> Again, in the context of a web based program, the
> die "some text", if shown to a visitor in a browser, is not going to
> help the programmer, and may just help someone figure out how to hack
> your program (especially if you are showing directory structures (ex:
> die "Could not write $file /home/sites/www.domain.com/users/
> webmaster")
>
> It would seem more logical to have some error recovery routine instead
> of a simple die. Somethig like:
>
> open(TMP, '>'.$file) or try &errorHandlingRoutine;
What is "try"?
Anyway, you can use eval to catch exceptions, so you can do something
like:
eval {
my $reply = fetch_content();
print "Content-Type: text/html\n";
print "\n";
print $reply;
}
if ($@) {
print STDERR "$0: $now: $$: $@\n";
print "Content-Type: text/html\n";
print "\n";
print friendly_error_message($@);
}
Then your code can die() anywhere within fetch_content or any function
called from it (even some library function not under your control) and
you still get both a good log file entry and a friendly message for the
user.
> Where if there was a failure it would execute the
> &errorHandlingRoutine to attempt to fix the problem and then restart
> the same line. The &errorHandlingRoutine could then "die" if it
> couldn't fix it.
>
> The perldocs say that you can have die almost do as I suggested, but
> you can not return to the same line to try again.
I don't see how your errorHandlingRoutine could do that either.
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
------------------------------
Date: Sat, 1 Sep 2007 16:23:54 +0200
From: Anno Siegel <anno4000@radom.zrz.tu-berlin.de>
Subject: Re: Why use die?
Message-Id: <5jtavqFrpb6U1@mid.dfncis.de>
On 2007-09-01 12:43:51 +0200, Bill H <bill@ts1000.us> said:
> Just to preface the following so I don't get the "daily WTF" or
> comments on code, I am not a "perl guru", I write code everyday in
> perl, and though good at it, I will be the 1st to admit I don't know
> everything.
Always be prepared for code comments.
> I see examples like this in many programs, where you try to open a
> file for write and you have a "die" statement after it:
>
> open(TMP, '>'.$file) or die "Can't create file";
The better examples show the file name and the system error in the
message:
open my $tmp, '>', $file or die "Can't create file '$file': $!";
(Also note use of lexical file handle and three-argument open())
> My question is, why would you use the "die" statement, ESPECIALLY in
> the context of handling web based requests?
Using "die" is just the generic way of error handling. The main point is to
deal with open() errors at all, instead of just ploughing on with an unopened
file handle. In practice, all kinds of variants can be seen, ranging
from simply
skipping intractable files
for my $file ( @files ) {
open my $fh, '<', $file or next;
# ...
}
to elaborate recovery schemes
if ( open ... ) {
# normal processing
} else {
# do something else instead
}
The salient point is *never* to expect an open() (or any critical
system call, for that matter) to succeed. All system commands
in Perl return a success indicator. Check it, always.
> If you are controlling all of the inputs, filename, permissions, etc
Your program doesn't (necessarily) control all these.
> and using flock, what is the need for a "die" statement?
>
> It is not accomplishing anything, other than telling you that it could
> not open the file, but again, if you control all the parameters then
> it should be able to open the file everytime.
Disk full? Hardware failure?
> If not, then it would
> seem that the programmer did not anticipate everything that could stop
> his program from working as expected.
Files are an external resource. The success of open() depends not only
on the program but also on things that happen while the code is unchanged.
It is never a good idea to assume a file that could be opened today can
be opened tomorrow.
On the other hand, if you *have* managed to think of everything, "or die"
doesn't hurt because it will never be called. Its presence doesn't stop
you from taking precautions.
> Also, when perl is used as web based program,
Some perl programs are used that way (though "web-based" isn't quite
the right term), but not all by a long shot.
> the die "some text"
> isn't going to do anything except trigger a Server Error
That would depend on the relative placement of header-printing and
file-opening. OTOH, often "Internal Server Error" is exactly the thing
to announce when a file has gone missing (or has changed permissions,
or what have you).
> because you
> do not have it in an HTML wrapper, unless you are using Carp, or it is
> putting it in some log for later viewing (or I could be off on this,
> if so let me know).
The error log of the http server process, usually. Later viewing is what web
developers want when they learn that certain requests have started to fail.
> Again, in the context of a web based program, the
> die "some text", if shown to a visitor in a browser, is not going to
> help the programmer, and may just help someone figure out how to hack
> your program (especially if you are showing directory structures (ex:
> die "Could not write $file /home/sites/www.domain.com/users/
> webmaster")
Right. That's why the default behavior is not to show error messages
to users. Things like "use CGI::Carp qw(fatalsToBrowser)" are definitely
not meant for production but debug situations only.
> It would seem more logical to have some error recovery routine instead
> of a simple die. Somethig like:
>
> open(TMP, '>'.$file) or try &errorHandlingRoutine;
Don't call subs with "&" unless you want the associated special effects.
What is "try"?
> Where if there was a failure it would execute the
> &errorHandlingRoutine to attempt to fix the problem and then restart
> the same line. The &errorHandlingRoutine could then "die" if it
> couldn't fix it.
Sure. That's often done. If you want to restart the statement, do something
like
errorHandlingRoutine() until open(...);
Here errorHandlingRoutine() *ought* to die if it doesn't find a promising
recovery, or you'll run an infinite loop.
> The perldocs say that you can have die almost do as I suggested, but
> you can not return to the same line to try again.
See above.
> Now knowing perl and the millions of module available out there,
> something similar probably exists, but, if it does I have not seen
> it.
The standard formula
open(...) or die "...";
is just a reminder that open() can fail anytime. In view of the fact that
a user can "eval { sub_that_max_possibly_die( ...) };" to do their own
error processing, it is pretty much universally applicable. If you have
better error handling, use it. There's nothing sacred about "or die".
Anno
------------------------------
Date: Sat, 1 Sep 2007 16:34:28 +0200
From: "Petr Vileta" <stoupa@practisoft.cz>
Subject: Re: Why use die?
Message-Id: <fbbtd4$2l61$1@ns.felk.cvut.cz>
Bill H wrote:
> I see examples like this in many programs, where you try to open a
> file for write and you have a "die" statement after it:
>
> open(TMP, '>'.$file) or die "Can't create file";
>
> My question is, why would you use the "die" statement, ESPECIALLY in
> the context of handling web based requests?
[...stripped...]
> Again, in the context of a web based program, the
> die "some text", if shown to a visitor in a browser, is not going to
> help the programmer, and may just help someone figure out how to hack
> your program (especially if you are showing directory structures (ex:
> die "Could not write $file /home/sites/www.domain.com/users/
> webmaster")
For web scripts I use some like
my $ok=1;
open(TMP, '>'.$file) or sub {print "Can't create temporary file.<br>Please
contact webmaster"; $ok=0;}
if($ok) { # then write something to file}
# continue if possible
--
Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)
------------------------------
Date: Sat, 01 Sep 2007 14:53:19 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Why use die?
Message-Id: <Xns999E6EB9A1775asu1cornelledu@127.0.0.1>
Bill H <bill@ts1000.us> wrote in news:1188643431.621334.88240@
57g2000hsv.googlegroups.com:
> I see examples like this in many programs, where you try to open a
> file for write and you have a "die" statement after it:
>
> open(TMP, '>'.$file) or die "Can't create file";
As others have noted,
open $tmp_fh, '>', $file
or die "Cannot open '$file' for writing: $!";
> My question is, why would you use the "die" statement, ESPECIALLY in
> the context of handling web based requests?
Because,
> If you are controlling all of the inputs, filename, permissions, etc
> and using flock, what is the need for a "die" statement?
you do not control the universe. There are many things that can go wrong
at the most inopportune times (disk full, kernel bug, data corruption
etc etc).
> seem that the programmer did not anticipate everything that could stop
> his program from working as expected.
The programmer cannot anticipate everything but he can anticipate that
when a call might fail, it will occasionally fail.
> Also, when perl is used as web based program, the die "some text"
> isn't going to do anything except trigger a Server Error because you
> do not have it in an HTML wrapper,
In real life, you get to decide how you communicate with the web site
visitor that an error has occurred. However, you als need the
information in the server logs to diagnose the problem. Depending on
your needs, it might be advisable to set up a script as the error
document handler to inform you of each error by email as well as
producing a human friendly error message for the web site visitor.
In toy programs, the important thing is to have checked for failure on
all calls that that might fail not how it is communicated to the end
user.
> your program (especially if you are showing directory structures (ex:
> die "Could not write $file /home/sites/www.domain.com/users/
> webmaster")
The solution is not have these messages shown to the web site visitor.
In moderately complex web applications, I prefer to keep an application
log file in addition to the server log file.
> It would seem more logical to have some error recovery routine instead
> of a simple die.
A simple die is the least that can and ought to be done when a call that
is essential to the correct functioning of the program fails. That does
not mean you can't add niceties.
> The perldocs say that you can have die almost do as I suggested, but
> you can not return to the same line to try again.
I frequently use
eval {
something that can fail or die " ... $!"
something else that can fail or die " ... $!"
another call that can fail or die "... $!"
etc
};
if( my $fail_message = $@ ) {
write the failure to application log file
present user friendly error message
}
See also
http://www.stonehenge.com/merlyn/WebTechniques/col54.html
where Randal's script tries ten times to lock a file before giving up.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
clpmisc guidelines: <URL:http://www.augustmail.com/~tadmc/clpmisc.shtml>
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 814
**************************************
