Re: Error handling strategies (db related)

On Tue, Apr 27, 2010 at 03:41:04PM +0200, Peter Lind wrote: > On 27 April 2010 15:36, Paul M Foster <paulf@quillandmouse.com> wrote: > > On Tue, Apr 27, 2010 at 10:42:03AM +0200, Gary . wrote: > > > >> How do you guys handle errors during, say, db insertions. > >> > >> Let's say you have an ongoing transaction which fails on the n-th > >> insert. Ok, you roll back the transaction, no problem. How do you then > >> inform the user? Just using the text from pg_result_error  or > >> something? > > > > I use trigger_error() and stop execution at that point. I give the user > > an error that basically says, "Talk to the admin/programmer". And I send > > the programmer a message containing a trace of what occurred. The theory > > is that, all things being equal, such an error should never occur and > > there is no user recovery. If the user properly entered the data they > > were asked for, then the transaction should go through without incident. > > If something prevents the transaction from going through, it's likely a > > coding problem and up to the programmer or admin to repair. > > > > Fair reasoning, but it amounts to throwing a bucket of cold water in > the face of your user. If I was looking at an error like that, I'd get > mighty annoyed with the software, and after a while would definitely > look for alternatives. Whether or not there's a coding problem, you > have to look at the situation from the point of the user: a complete > failure with no information is like a BSOD/TSOD ... and we all know > the effect they have on a user. I assume (1) that I've vetted the user data and given them the option to repair it if it's faulty; (2) beyond the beta phase, this type of error should not happen. If it does, it's a coding problem. Given that the user can do *nothing* about this and it *is* a coding problem, what would you tell the user? If I was the user, I'd be cranky as well. But if I were a smart user, I'd realize that the programmer made a mistake and put the responsibility firmly on him. And expect him to fix it pronto. Paul -- Paul M. Foster