On Oct 26, 2009, at 8:16 PM, Peter Foelsche wrote:
"David Bergman" <David.Bergman@bergmangupta.com> wrote in message news:080E88A6-D02B-4AAD-B2FC-B9E6A8E97F5C@bergmangupta.com ...
Agreed. I am a huge proponent of using exception handling instead of error codes (virtually everywhere), but considering that ASIO is one of the best, and most cleverly, designed C++ libraries ever made (up there with Boost.Graph and Boost.MPL), one should be a tad careful before bantering like that. The likelihood of one's being a better C++- using designer than Christopher is not that high, statistically speaking...
I've a lot of respect for some parts of the boost library -- e.g. mpl. I learned a lot from using the mpl. I also learned a lot from boost::variant and boost::any.
Did you actually read my posts?
Nope, just that particular uncalled for, and quite personal, bantering line.
He designed a socket library, which is full of protocols (Protocol is my word for a class-design, which requires that methods of an object be called in a particular order.). He also does not understand the usefulness of exception handling in larger software projects.
I suspect you have a point you would like to make about the interface. If you keep the personal attacks out of the statement you will be more clearly heard.
If I were Christopher, I would kindly ask for instances in the ASIO library where exception handling would help readability, performance or any other aspect. I think there might be such cases, but that would be like whining about a pimple on Halle Berry's face.
I think in 1996 I designed some classes to wrap UNIXs socket and io calls. There was a socket class calling socket() in the constructor and close() in the destructor without any other methods. This class does not need to be public, as it is useless for the enduser. Then there are classes, * which connect to a well known address (for usage as a client) * and a class calling bind() and listen() to a wellknown local address (for usage as a server) -- both classes are based on the socket class.
These classes have cast functions to cast into a int -- the filedescriptor.
Then there are implementation of some read-from-somewhere interface and some write-to-somewhere interface -- reading from a filedescriptor and writing to a filedescriptor. Such implementations of read-from-somewhere and write-to-somewhere can be combined to produce cached reading and writing.
Then there was another layer using the XDR libraries to deal with machine independence, which was pretty complicated due to the crazy XDR interface (which UNIX API is not crazy?).
And I think I had to deal with various UNIX hacks, like e.g. connect () returning immediately.
The write-system call also had to be wrapped by setting/resetting the signal handler for SIGIO.
I have written many such wrappers, and one very similar to this description - even using XDR - in 1992.
All of these functions threw on error -- a system error object. This made debugging server-client systems much more easier than before, since now people knew the system error and the method which failed and maybe even the call-stack of the failed operation:
Cannot start postprocessor in client mode! Because of Cannot connect to "hostname":portnumber! Because of No such host! ("Hostname").
I was only dealing with TCP/IP and not UDP.
Your argument is valid in most circumstances, but there are a few where error codes is more proper, as has been pointed out a few times on this list, such as when embedded environments without exception handling is targeted. OR: in asynchronous cases involving callbacks, which is often the case with Boost.Asio. Let us instead see how we can help Christopher improve (the already magnificent) Boost.Asio, by showing how exception handling would make code more readable/performant/whatever in that particular library. /David