On Tue, 22 Oct 2019 at 14:38, Benjamin Morel <benjamin.mo...@gmail.com> wrote:
> > I used this one function as an example, but I'm happy to apply my point of > view to other examples if you wish. > You have phrased this as though your point of view is different from mine, but I think you've just misunderstood it. I said: > All of these are candidates for returning false, or an error code, or an object in a particular status. That's precisely what your examples show: the functions returning false. So we're in agreement, some errors should become exceptions, others should be handled a different way, and some cases need new functions. > This proposal would be as good under the form of a new API though, but in > this case the naming should be changed to clearly differentiate both APIs. > Yes, new names is almost entirely the point of "a new API". The idea is that you don't have to recalibrate people's expectations of what fopen() does, breaking thousands of lines of existing code, nor compromise the design to minimise that impact. Instead, you say "here's a new function, it has these nice features, and handles errors in this really smooth way, please use it" - and more importantly, "here's a consistent set of functions which all work in this same way, please use them". Finally, to reiterate what's been said several times, there are definitely functions where the error cases are so "exceptional", that just throwing an exception would be perfectly fine. It's the commonly used sets of functions with a variety of different error conditions and use cases, like file handling, where more careful redesign is prudent. Regards, -- Rowan Tommins [IMSoP]
