Re^2: WWW::Mechanize - error on geting non-existing page
by Your Mother (Archbishop) on Nov 05, 2011 at 23:22 UTC
|
You can also just set onerror => undef which is easier and less error prone than eval/try style code.
| [reply] [Watch: Dir/Any] [d/l] |
|
| [reply] [Watch: Dir/Any] |
|
…well, all examples really. Though it depends on how you see it. I never advocated ignoring return states.
Not finding a page online is not an exception(al case). It’s entirely normal. Should your car blow-up if a road-sign is missing or should the driver revisit the map? If you need to deal with any of the various 400s and 500s, it’s just easier on the hacker to not wrap it up in evals. The end code will have identical functionality: i.e., every request is checked for success or unexpected codes and then processed accordingly. All the exception handling buys you here is additional complexity (and the chance to fall into eval problems with disappearing $@ if you’re not careful).
The change to make this stuff fatal by default is recent-ish. For most of the life of Mech, it wasn’t this way so it was a pretty big style break for those of us using it from the beginning, and I think most LWP hackers are already accustomed to checking $response->is_success habitually.
There may be some value in the fatals for the newcomer who has incorrect expectations but for the experienced user of the kit it’s just an annoying hoop (and a bunch of broken scripts when the update came through but I digress… uh, and whine).
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
|
|
|
Re^2: WWW::Mechanize - error on geting non-existing page
by cavac (Parson) on Nov 05, 2011 at 20:43 UTC
|
| [reply] [Watch: Dir/Any] |
|
You also might want to switch to WWW::Mechanize::GZip, since some versions of the original WWW::Mechanize seem to announce to handle HTTP compression but don't in reality. This might result in "unparseable" results returned from the webserver.
I doubt this ever happens :) but if it did, the solution is to always install the latest WWW::Mechanize , LWP, Compress::Zlib
If you were going to install WWW::Mechanize::GZip, you might install the latest WWW::Mechanize , LWP, Compress::Zlib instead
| [reply] [Watch: Dir/Any] |
|
Thanks for the info. I had the problem a few months ago on Windows (for a windows service compiled with the ActiveState tools) after upgrading Maplat with the compression options. Took me a while to figure out the root of the problem and/while it affected production - so i grabbed at the first straw i could find. So far, hasn't let me down yet.
But i'm gonna try it your way. Sounds a bit saner than what i had come up with. Thanks.
Don't use '#ff0000':
use Acme::AutoColor; my $redcolor = RED();
All colors subject to change without notice.
| [reply] [Watch: Dir/Any] |
|
Anonymous Monk,
I doubt this ever happens :)
Until today, I would have agreed with you. See Re^2: What Tools Do You Use With WWW::Mechanize. Essentially, $mech->mirror() will not decompress the file but that doesn't mean that Mech can't handle compression (I provide an alternative way of downloading the file that works just fine in the node).
| [reply] [Watch: Dir/Any] |
Re^2: WWW::Mechanize - error on geting non-existing page
by Anonymous Monk on Nov 05, 2011 at 23:09 UTC
|
Thanks a bunch, problem solved! | [reply] [Watch: Dir/Any] |