On May 10, 3:01 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > Graham is right. The best we can do is catch > > try: > data = src.read(size) > except: > raise MySocketException > > and catch it later as I suggested above. What do you think?
You can't technically do either of the things you have suggested, ie., catch all or catch just IOError. In WSGI you might not be reading direct from the original wsgi.input but from a WSGI middleware. It may introduce its own sort of IOError for totally different reasons and may raise exceptions for other reasons. If you blindly catch all exceptions or even just of type IOError, you may mask totally unrelated errors and make it extremely difficult for people to debug things. As I said in my original post, the best you can do is to propagate up the original exception, but have any system which catches uncaught exceptions and mails out details be able to be configured by a user (not by default), such that the user can specify exception types and exception descriptions which can be ignored for the particular hosting system or combination of WSGI middleware they use. Graham > Massimo > > On May 9, 11:52 pm, Graham Dumpleton <graham.dumple...@gmail.com> > wrote: > > > > > On May 10, 1:51 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: > > > > Ticket. I usually see them the next day when I check admin. > > > > No, it is usually just one IP but it happens to a lot of people at the > > > same time, scaled by the amount of traffic being put on the server. > > > Then it is likely that the ISP or network all the requests were routed > > by dropped all the connections for whatever reason. > > > > Roughly about 10% of the requests generate this error. > > > > > A user not waiting for a request to complete before clicking on > > > > another link or pressing reload. In other words, client dropped > > > > original connection. > > > > Obviously this is a web2py issue then, because I don't have any > > > problems when I go click-happy on other web sites. > > > Part of the problem is that there is no standard for what type of > > Python exception is generated by a dropped connection. The mod_python > > and mod_wsgi package so happens to use IOError, but different > > descriptions. Other WSGI servers are within their rights to use a > > completely different Python exception or yet another description > > against an IOError. Thus, it becomes really hard for a generic > > framework that can be hosted in various ways to make a judgement as to > > whether a failure on read was due to a particular type of error. Thus > > it becomes hard to ignore errors for loss of connection. You also by > > ignoring them, limit an applications ability to take some special > > action when connections are dropped. > > > It therefore isn't obvious what to do and most Python frameworks will > > as a result just pass the exception up the stack and cause a 500 > > response. If you have a mailout option for errors back to system > > administrators then you obviously may get an lot of emails. Best you > > might do is for that mailout middleware to allow a user to supply > > their own rules, ie., exception types and desription regex, for things > > that should be ignored as far as mailout message to admin. > > > Graham > > > > On Sun, May 9, 2010 at 9:55 PM, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > > ure about the problem but I had a few instances of people > > > > clicking reload a lot (and I mean a lot). So I use thi
