Re: [boost] [system][filesystem v3] Questionabout error_codearguments

Subject: Re: [boost] [system][filesystem v3] Questionabout error_codearguments
From: David Bergman (David.Bergman_at_[hidden])
Date: 2009-10-26 23:35:10

On Oct 26, 2009, at 8:16 PM, Peter Foelsche wrote:

>
> "David Bergman" <David.Bergman_at_[hidden]> wrote in message news:080E88A6-D02B-4AAD-B2FC-B9E6A8E97F5C_at_[hidden] 
> ...
>
>> 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