On Sunday 15 August 2010, it occurred to bvdp to exclaim: > Assuming I have a module 'foo.py' with something like this: > > def error(s): > print "Error", s > sys.exit(1) > > def func(s): > ... do some processing > ... call error() if bad .. go to system exit. > ... more processing > > and then I write a new program, test.py, which: > > import foo > > def myerror(s): > print "new error message" > > foo.error = myerror > > a = foo.func(..) > > Now, if an error is encountered myerror() is called. Fine. But > execution resumes in func(). Not exactly what I wanted. > > I can "fix" this simply by wrapping the call to foo.func() in a try/ > expect and have myerror() raise an exception. This appears to work, > but I'm hesitant to use this out of fear that I'm building up some > kind of stack overflow or something which will bite me later.
An exception will walk up the stack, calling any cleaning-up code that needs to be done (removing object references, executing finally: blocks, exiting context managers properly. It won't break anything. Don't be afraid of Python's high-level features! > > Is there a better way? Simplest for an old assembler guy like me would > be pop a return address off the stack ... but python isn't > assembler :) Now that has a decent chance of messing things up and you (if you wrote decent assembly ;-)) know it -- without properly cleaning up before resuming execution in the right place, you could end up in a right state with memory leaks, leaked file descriptors, half-arsed database transactions, etc etc. > > I don't want to change stuff in the foo.py module since it's part of > an existing program. But, if I must, I suppose I could. I'd prefer to > just short-circuit this if possible. Exceptions. Simple. In the end, all system.exit does is raise a SystemExit exception... - Thomas -- http://mail.python.org/mailman/listinfo/python-list
