On 11/18/2013 2:16 PM, Jonathan M Davis wrote:
Sometimes that's true, but if you're asserting that it's not going to be the
case that folks are going to need to calling functions which can throw but
won't throw from inside nothrow functions, I think that your dead wrong. If
nothing else, you don't always have control over what is and isn't going to
throw. Maybe it's uncommon enough that it's not worth trying to optimize out
the try-catch blocks, but I think that asserting that you won't ever need to
call a throwing function from a nothrow function when you know it won't throw
is like asserting that @trusted isn't needed.
What I'm saying is it is bad API design to conflate data processing with input
data validation. You may not always have control over the API design and may
have to live with bad API design, but in std.datetime's case we do have control
and we can do the right thing.
Joel Spolsky wrote a nice column
http://www.joelonsoftware.com/articles/Wrong.html about this years ago, about
conceptually separating input data validation operations from data crunching
operations. This distinction is baked into D's design:
exceptions - input data validation
asserts - crunching on data that has been validated
Code like this:
try {
func();
} catch (Exception e) {
assert(0, "func() should not have thrown");
}
clearly shows a design failure, either in func()'s design or how func() is used.
