try/catch idiom in std.datetime

Jonathan M Davis jmdavisProg at gmx.com
Mon Nov 18 13:16:23 PST 2013


On Monday, November 18, 2013 11:44:46 Andrei Alexandrescu wrote:
> That 7 issues with as many try/catch instances, i.e. 13% of the total
> 54. You may think I cherry-picked them; in fact, they are the FIRST 7
> instances I found by simply searching the file for 'try'. I have no
> reason to believe I won't find similar issues with most or all of them.
> 
> I think std.datetime needs a pass with an eye for this idiom and
> obviating it wherever possible.

Clearly, I need to take a look at this. I don't think that I ever made an 
attempt to avoid the try-catch-assert(0) idiom. I used exceptions where they 
made sense and then used try-catch-assert(0) where it was required in order to 
mark functions as nothrow when I knew that they logically could/should be 
nothrow. On the whole, I think that the implementaton of std.datetime is good, 
but my primary focus was always on the API, and it was a lot of code for 
people to review, so it's not entirely surprising if some things could/should 
be improved. There were a _lot_ of improvements thanks to the review process, 
but that doesn't mean that everything was caught. It's also the case that 
we've all learned quite a bit in the years since, and the compiler and 
libraries have improved as well, changing what does and doesn't work in some 
cases (e.g. any function with format is currently impure in std.datetime, but 
it now may be able to be pure). So, it should now be possible to improve some 
of std.datetime's implementation beyond what we could do when it was first 
introduced.

Once I've finished splitting std.datetime (which is mostly done, but I've been 
too busy lately to finish quite yet), I'll look into reducing the number of 
instances try-catch-assert(0) in std.datetime as well as looking for any other 
implementation improvements which can be made. And that's one thing that the 
plethora of unit tests makes easier, because the risk of breaking stuff and not 
catching it is fairly low (in fact, Martin Nowak made improvements to a 
function in core.time recently and expressed that he was glad for how much 
easier it made it to catch mistakes in his refactor because of how thorough 
the tests were).

- Jonathan M Davis


More information about the Digitalmars-d mailing list