| Re: From city to lati and long [message #175032 is a reply to message #175031] |
Thu, 04 August 2011 19:22   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 8/4/2011 3:17 PM, Denis McMahon wrote:
> On Thu, 04 Aug 2011 14:24:31 -0400, Jerry Stuckle wrote:
>
>> If you read her post, sometimes the code works and sometimes it fails -
>> with *exactly the same parameters*. The problem is NOT the PHP code.
>
> Yes, and perhaps using a better method (curl vs file) for getting the web
> page might enable her to determine that sometimes she gets something
> other than the data that is expected. For example, maybe she gets a 4xx
> page and is trying to parse the first line of that with explode?
>
> Her error then would be failing to handle the 4xx page appropriately, or
> even treating it as valid data.
>
> Likewise validating that the contents of the received file met some basic
> criteria might help detect errors, and knowing what was being received
> when invalid data was generated by the explode could certainly help in
> determining what was causing the problem.
>
> But I'm glad that you reject all of these possible php steps she could
> take to identify and solve her problem as irrelevant to discuss here
> because her problem doesn't fit your smallworld view of a php problem.
>
> As I said, the underlying problem might not be the php code, but surely
> just as it is good practice to validate and verify everything one
> receives as form input before doing any calculations with it, so it is
> also a good idea to validate and verify that any data obtained from an
> external server is in an expected format before attempting to process it
> further ... which is part of what I am suggesting she do. The other parts
> of what I am suggesting she do are to use functions that give her a finer
> degree of control and feedback over the http request she makes, and that
> if she does detect an error, she records as much of the relevant data as
> possible for analysis to help determine the fault. These are all things
> that she can do in php that may help her discover what the issue is and
> find ways in php to mitigate (wait a few secs and retry the request
> perhaps if she gets an "upstream server error" or timeout type response)
> or gracefully fail.
>
> Rgds
>
> Denis McMahon
Sure, I reject them - because I believe in finding the PROBLEM - not
guess and try things until something might work *right now*. She can
do that - she can jump up and down on the sofa, or hold her breath until
she's blue in the face. All have an equal likelihood of finding the
problem.
Without knowing the cause of the problem, you don't know if it's fixed
or not. Maybe it's gone away for now, for instance. Or maybe it only
happens under specific server or network conditions.
And without finding the problem, you don't know if you have it solved.
But hackers don't care about that. All they care is finding something
that works *right now*. Real programmers care about finding something
that works *all the time*.
And when you do find the source of the problem, often the code to solve
the problem becomes much easier and straightforward. Not always -
sometimes it's the code on the server which needs to be fixed, for instance.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]