try/catch idiom in std.datetime

[Jonathan M Davis]

On Monday, November 18, 2013 13:50:42 Walter Bright wrote:
> On 11/18/2013 1:23 PM, Jonathan M Davis wrote:
> > Then what would you suggest for dealing with cases where a nothrow
> > function
> > calls a function which can throw in general but can't throw with the given
> > arguments? Completely separate from the issue of whether std.datetime
> > should need to be calling a throwing function from a nothrow function as
> > often as it does, it's still an issue which must be dealt with in
> > general. At present, any nothrow function which wants to call a throwing
> > function needs to use a try- catch block to wrap the throwing function,
> > and it makes good sense to use assert(0) to catch the case where the
> > caller screwed up and the function can indeed throw. However, given that
> > that throwing function should never throw, it's desirable to be able to
> > optimize out the try-catch-assert(0). How would we do that without taking
> > advantage of the fact that assert(0) indicates that that line of code
> > should be unreachable?
> 
> I believe this is solving the problem in the wrong place. The function being
> called should not be throwing, and should be defined as not throwing. See
> my other posts in this thread on the topic.

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.

- Jonathan M Davis