Re: [boost] [system][filesystem v3] Question abouterror_codearguments

Subject: Re: [boost] [system][filesystem v3] Question abouterror_codearguments
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2009-11-01 17:27:13

"Emil Dotchevski" <emildotchevski_at_[hidden]> wrote in message
news:c72e33ce0910281601i358d695dw88cd851b001d39ae_at_mail.gmail.com...
>>>On Wed, Oct 28, 2009 at 12:40 PM, Detlef Vollmann <dv_at_[hidden]> wrote:
>>>> Domagoj Saric wrote:
>> i mentioned the latter 'issue' already in the first post...
>> generally both points seem to me like non-issues because they cannot become
>> issues unintentionally...
>> both can come into play _only_ if the user converts the temporary return
>> object
>> into a local scoped object/variable...which, as far as i know, you cannot do
>> 'by accident'/unintentionally...you have to be verbose about it...(although,
>> ironically the new auto makes it easier for you to do "the wrong
>> thing"...but
>> still not easy enough that you can do it by a 'non conscious mistake')...
>
>It

sorry is "It" an acronym i'm not familiar with or you just forgot to finish
your sentence? ;)

>Assuming that there is an agreement that the user *knows* if she wants
>an exception or an error code,

well i'd say it's pretty obvious that the user knows...in the sense that you
can/have no other option but to assume that the user knows...because as a user
you are always forced to either learn the options of a tool that you use (in
order to be able to use it at all) _or_, _if_ your tool provides some defaults
you have the option of sticking to the defaults...
...same situation here...if the user knows his/hers preferences great, if not
than the default policy will be "in charge"...

what's the difference between that and the status quo?
you also currently have functions that throw, that return an error or do both
or some fourth wild thing...as a user you always have the option of either
ignoring all that and live in some fanatasy world and "create bad software that
works only on every other sunny thursday" or to "know your stuff"...
...i must admit not to understand this point...its like worrying whether the
user will know that new throws or returns null or which new and malloc handler
to use...it doesn't seem like something to base design decisions on...in this
day and age you can still find loads of people and libraries that still do not
use new 'right'...(e.g. pick any of your favorite gui library...usually the
bigger/bloatier and more popular the crappier code...)...yet that is not the
reason why to ashew new and go back to malloc...

> why not provide two functions: one that
>returns an error code, and another one that calls the first one and
>throws on error?

because that seems more complicated and less powerfull and configurable (to me, 
from the current
perspective)...

- you'd have to write and maintain a 'tremendous' amount of boilerplate code
(with an added overload for every existing function and overload)...
- the only way to configure the behaviour (choose a policy, what i mentioned in
the first post) would be using macros...plus you still wouldn't have a 
mechanism that asserts that you checked the return of an overload that does not 
throw but returns an error code...

-- 
 "That men do not learn very much from the lessons of history is the most
important of all the lessons of history."
 Aldous Huxley