try/catch idiom in std.datetime

[Walter Bright]

On 11/20/2013 12:17 PM, Dicebot wrote:
> On Wednesday, 20 November 2013 at 20:06:04 UTC, Andrei Alexandrescu wrote:
>> What I meant is there are consistent styles that are objectively worse.
>> Consistency is necessary but not sufficient.
>
> And what I meant is this opinion of yours is wrong. Any consistent style that is
> liked by at least one programmer that uses it in practice is no worse than any
> other possible consistent style. There is nothing objective about it, pretty
> much as there are not that much common about human perception.

I'm going to very strongly disagree with this.

And I'll use a hoary analogy - airplane cockpit design. It doesn't matter how 
consistent it is - there are an awful lot of cockpit design features that have 
caused crashes, and the fix was changing the feature. These misfeatures were not 
technically faulty nor were they inconsistent. But they were still bad.

I'll give one example. Warning horns for things that went wrong were good 
features. So good, in fact, that designers added more and more horns. Each horn 
had a different sound signature. The horns were consistent, and worked 
faultlessly. Unfortunately, the plethora of horns caused pilots to get confused 
under stress, and they'd react to solve the wrong problem.

The solution was to replace the horn's siren with a voice saying what was wrong, 
such as "fire engine no. 2" and "pull up". This worked BETTER.

I see no difference with coding styles. Some are better, some are worse. As 
Andrei stated, consistency is not sufficient.

For example, no indenting at all. Consistent? Yes. Bad? Yes. Case closed!