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).
Bye,
bearophile
