On 02/10/2010 01:12, Chris Frey wrote: > I'd prefer DoRead() to handle all its own exceptions, but only its > own exceptions, and ones it knows how to handle. Any other exception > handling should probably be done in SimpleReadThread(), and > SimpleReadThread() should probably have a catch(...) with a large > logging message. > > My reasoning is that, in theory, an application can code its own > variant of SimpleReadThread(), and it may wish to communicate errors > from its own callback functions that DoRead() calls to the read thread > by means of exceptions. So application level exceptions should pass > right on through DoRead() and get caught in the application's > SimpleReadThread(). > > I'm thinking that even Usb::Error exceptions might need to be rethrown > so that SimpleReadThread() can see them. Our SimpleReadThread() will > probably just ignore everything and log it, but other variants might > want to do something with it. > > Basically, if we can recover, we should, but we shouldn't hide information > from the app, just in case it knows better than we do. > > What do you think? Over engineered? > No, sounds sensible. I've added an outer exception handler to my github branch in af595a6dbf1ded46a05a. I didn't put the exception handler outside the while loop as the code which closes the USB device assumes that the DoRead loop will run frequently so that it can be signalled when it's safe to close the USB device. I tired to use a semaphore for this, but I couldn't get it working reliably without hanging.
I also fixed a build error due to builder.h not including stdint.h in 679bf52d3bd1edffa874. I suspect that I must use slightly different configure options to you and so some other header file isn't including stdint.h before builder.h for me. Regards, Toby ------------------------------------------------------------------------------ Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
