Re^6: eval not working the way I expected?

I still don't understand why eval { } || 0 did not work though

eval doesn't affect warnings. And the warning occurred during the division, not after the eval was completed.

>perl -we"my $x; my $q = eval { $x / 4 } || 0;
Use of uninitialized value in division (/) at -e line 1.

>perl -we"my $x; my $q = eval { ($x||0) / 4 };

>perl -we"my $x; my $q = ( $x / 4 ) || 0;
Use of uninitialized value in division (/) at -e line 1.

>perl -we"my $x; my $q = ( ($x||0) / 4 );
[download]

Comment on Re^6: eval not working the way I expected? Select or Download Code

Replies are listed 'Best First'.
Re^7: eval not working the way I expected? by convenientstore (Pilgrim) on Jan 11, 2008 at 04:00 UTC
I was wish eval can wrap even the warnings but I guess that's not the purpose of the eval Do you guys normally run perl scripts that's written for production w/out -w ? I don't think having people seeing perl warning message is professional looking.. that's just my opinion	[reply]
Re^8: eval not working the way I expected? by parv (Parson) on Jan 11, 2008 at 05:14 UTC
If warnings can't be redirected to a accessible log file, next best thing is for the user to tell you about it. I would need to work very hard to find a reason to turn off the warnings, regardless of where a program might be running.	[reply]
Re^8: eval not working the way I expected? by ikegami (Patriarch) on Jan 12, 2008 at 05:39 UTC
I believe warnings should be fixed, not silenced. With that in mind, using `-w` is preferable since all warnings observed are bugs that need fixing. The bugs might be harder to detect without `-w`.	[reply] [d/l] [select]
Re^8: eval not working the way I expected? (production warnings) by tye (Sage) on Jan 12, 2008 at 06:34 UTC
Warnings (and, to some extent, errors) are only as valuable as the communication channel that gets them back to the person who can fix the problem that they tell of. Displaying a warning in "production" is usually not just unprofessional looking but also very often nearly useless because the warnings displayed are very unlikely to get back to the person who can "fix" the warnings with enough fidelity to be much use. For example, I don't "use warnings;" in my modules. I do, however, have "-w" on the #! line of the my t/*.t module test files. And I also use "-w" on the #! lines of the scripts that I personally use. This means that warnings are displayed when they will be displayed to me. They are also displayed when somebody tests my modules. So my code is well-tested as far as being unlikely to produce warnings. But my code does not produce warnings by default when other people use it. I would only enable warnings in production if I had already established the communication channel that gets the warnings faithfully back to me, which might also mean that the production users would not even see the warnings (if the "customers" of this production code were employees, they probably would; if they were external customers, they probably wouldn't). - tye	[reply]