try/catch idiom in std.datetime

Walter Bright newshound2 at digitalmars.com
Mon Nov 18 14:58:53 PST 2013


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.


More information about the Digitalmars-d mailing list