| Re: Adding a record to a database [message #175126 is a reply to message #175125] |
Tue, 16 August 2011 14:42   |
A.Reader
Messages: 15
Registered: December 2010
Karma:
|
Junior Member |
|
|
On Tue, 16 Aug 2011 14:51:27 +0100,
Tim Streater <timstreater(at)greenbee(dot)net> wrote:
> In article <ttnk47593ucb0h3crdh61kemnbuc88q5mr(at)4ax(dot)com>,
> A.Reader <anonymously(at)example(dot)com> wrote:
>
>> On Tue, 16 Aug 2011 06:23:06 -0400,
>> Jerry Stuckle <jstucklex(at)attglobal(dot)net> wrote:
>
>>> Better yet - get rid of the die() all together and handle the error
>>> gracefully. Then ask about the SQL problem in the appropriate newsgroup.
>>
>> We're talking about the debugging phase here, aren't we? There
>> shouldn't _be_ any sql errors left by rollout.
>>
>> And, from the error msg, the error doesn't represent an "SQL
>> problem" as such but rather a plain syntax error. My suggestion
>> was aimed at helping him improve his PHP code such that he could
>> then find the error. That seems to be within the remit of this
>> group.
>
> You're overlooking bugs in the implementations that you rely on, and
> obscure bugs of your own. I get occasional SQLite errors that I believe
> to be SQLite bugs, but I'm not 100% sure if that's true. I have my own
> wrapper on SQLite calls that uses try/catch, and logs errors to a
> logfile, with as much info as possible. This sort of approach should be
> designed in as soon as possible in the app.
>
> Just imagining that "there won't be any mysql (or whatever) errors by
> rollout" is naive.
We might be talking about two different things.
Nearly everything I've ever written has been console-bound, or
has been some utility that's going to be run as a batch job maybe
10 times at the most.
So I write in a very simple-minded, plodding way, and that seems
to protect me from those glitchy-type bugs that cause the mental
problems and premature aging. The bugs that show up, show up
early and tend to be pretty clearly Mine or Theirs.
But I agree with you (and Jerry) that production code should be
prepared to handle residual errors, and preferably in a classier
way than by just clutching its throat and going spark out.
I'd argue, though, that our friend Charles, here, is well before
needing to think about production issues. He's still trying to
get basic db-app code to do something besides halt and fall over.
For that stage of things, I find die() to be a usefully quick way
to deliver debug info.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]