Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Re^2: WWW::Mechanize - error on geting non-existing page

by Your Mother (Chancellor)
on Nov 05, 2011 at 23:22 UTC ( #936198=note: print w/replies, xml ) Need Help??

in reply to Re: WWW::Mechanize - error on geting non-existing page
in thread WWW::Mechanize - error on geting non-existing page

You can also just set onerror => undef which is easier and less error prone than eval/try style code.

Replies are listed 'Best First'.
Re^3: WWW::Mechanize - error on geting non-existing page
by Limbic~Region (Chancellor) on Nov 06, 2011 at 14:37 UTC
    Your Mother,
    I honestly can't think of any reason this might be true. Do you also establish a DBI connection without RaiseError set to true? It is akin to not checking the return code of open. If something goes wrong, I want to know about it very loudly instead of blindly assuming everything is ok.

    Can you give me an example of where setting it to false is better? I assure you I haven't adopted this strategy as a cargo cult practice and am genuinely interested in hearing your views on how this is better.

    Cheers - L~R

      …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).

        I hear where you are coming from, but it sounds a little like "We didn't have warnings in the past, we always checked using defined. Why should we switch to using them now?". To me the difference is between having to check everywhere and maybe getting bitten bad if you missed something, versus getting a noisy failure if something unanticipated happens.

        In most cases I'd rather have a noisy failure and deal with it than a quiet failure that may just plough on and destroy the world.

        True laziness is hard work
        Your Mother,
        If instead of:

        You can also just set onerror => undef which is easier and less error prone than eval/try style code.

        You had said:

        This behavior can be turned off by either setting onerror to undef or by turning autocheck off in the constructor. The purpose behind this was the author's attempt to protect new users from themselves. Just as you shouldn't assume that your call to open was successful, you shouldn't assume your call to get was either. It will be your responsibility to check each success for is_success/status and handle any recoverable situations yourself if you do this.

        I would never have commented. Personally, I like having the code blow up to remind me of places I haven't properly checked the status and leave it on by default but I can see your point as well.

        Cheers - L~R

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://936198]
[robby_dobby]: CPUlidster: Eh, what? That's Louvre, right?
[CPUlidster]: 20yrs since I visited.

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (11)
As of 2017-12-15 10:57 GMT
Find Nodes?
    Voting Booth?
    What programming language do you hate the most?

    Results (431 votes). Check out past polls.