[Twisted-Python] Newbie question about error handling.
bnsmith at gmail.com
Sat Jan 19 13:56:26 EST 2008
You've given me two really good ideas to mull over. Of course, the
decorator method would work. It was like a flash of light as soon as I
read it... but now I'm not sure if I should...
Thanks for the help.
On Jan 18, 2008 6:03 PM, Drew Smathers <drew.smathers at gmail.com> wrote:
> On Jan 18, 2008 4:23 PM, Brad Smith <bnsmith at gmail.com> wrote:
> > Suppose that an exception is thrown in lineReceived or
> > rawDataReceived, maybe just something as simple as a naming error
> > caused by a misspelled variable name. Is there any way to implement a
> > default exception handler that would allow me to send something back
> > to the client before the protocol dies? It would be nice to send the
> > exception traceback to the client to help figure out what went wrong.
> > I suppose I could wrap all of the methods in the class in a try/catch
> > block, but that would be a lot of wrapping to do. I'd prefer to be
> > able to do something like adding a 'defaultExceptionHandler' method to
> > the LineReceiver derived class that would be called by the reactor.
> It will save you more time to fix such a critical bug as a naming error
> rather than build a protocol to only tell the client the server is broken.
> However to answer your question, no.
> Remember from the Zen of Python: "explicit is better than implicit" so to
> handle legitimate errors you should define what exceptions are likely to
> occur and incorporate these in your protocol design for error feedback to
> the client. If you want some kill-all exception handler for all your
> protocols, consider writing a decorator:
> def lineReceived(self, line):
> pass # do stuff
> \\\\/ // //\/\\\\\\\
> \\\/ \\// /\ \/\\\\
> \\/ /\/ / /\/ /\ \\\
> \/ / /\/ /\ /\\\ \\
> / /\\\ /\\\ \\\\\/\
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
More information about the Twisted-Python