List of Phobos functions that allocate memory?

[Jonathan M Davis]

On Friday, February 07, 2014 21:27:04 bearophile wrote:
> Jonathan M Davis:
> > 3. Code which should succeed most of the time but where doing
> > validation
> > essentially requires doing what you're validating for anyway.
> > Again, parsers
> > are a good example of this. For instance, to validate that
> > "2013-12-22T01:22:27z" is in the valid ISO extended string
> > format for a
> > timestamp, you have to do pretty much exactly the same work
> > that you have to
> > do to parse out all of the values to convert it to something
> > other than a
> > string (e.g. SysTime). So, if you validated it first, you'd be
> > doing the work
> > twice. As such, why validate first? Just have it throw an
> > exception when the
> > parsing fails. And if for some reason, you expect that there's
> > a high chance
> > that the parsing would fail, then you can have a function which
> > returns an
> > error code and passed out the result as an out parameter
> > instead, but that
> > makes the code much uglier and error-prone. So, in most cases,
> > you'd want it
> > to throw an exception on failure.
> 
> Languages with a good type system solve this with Maybe /
> Nullable / Optional and similar things. It's both safe (and
> efficient if the result is equivalent to just a wapping struct).

That can be a good solution, but it also then requires checking the result. 
One of the big advantages of exceptions is that your code can not care except 
for the relatively few points that catch exceptions and handle them. Where you 
run into problems is when the failure case is likely. And if that's the case, 
then something like Maybe or Nullable is definitely better.

- Jonathan M Davis