"Emil Dotchevski" <emildotchevski@gmail.com> wrote in message news:c72e33ce0910281601i358d695dw88cd851b001d39ae@mail.gmail.com...
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
On Wed, Oct 28, 2009 at 12:40 PM, Detlef Vollmann <dv@vollmann.ch> wrote: 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