DIP 1029---Add throw as Function Attribute---Community Review Round 1

[Guillaume Piolat]

On Tuesday, 14 January 2020 at 23:04:02 UTC, Adam D. Ruppe wrote:
> On Tuesday, 14 January 2020 at 22:30:40 UTC, Walter Bright 
> wrote:
>> Hence, when "nothrow" becomes the default
>
> IF, not when. I support this DIP as a nice independent move, 
> but I am going to fight you on the step of changing the default.
>

+1 it's a strange misguided idea in the absence of something 
better than exceptions.


In my best passive-aggressive way, let me quote:

"The basic answer is: Using exceptions for error handling makes 
your code simpler, cleaner, and less likely to miss errors."

[C++] Why use exceptions? 
https://isocpp.org/wiki/faq/exceptions#why-exceptions


"What do you do when an error occurs in a program? In many 
languages, error conditions are signaled by unusual return values 
like 1. Programmers often don't check for exceptional values 
because they may assume that errors "can't happen." On the other 
hand, adding error detection and recovery to what should be a 
straightforward flow of logic can complicate that logic to the 
point where the normal flow is completely obscured. An ostensibly 
simple task such as reading a file into memory might require 
about seven lines of code. Error checking and reporting expands 
this to 40 or more lines. Making normal operation the needle in 
your code haystack is undesirable."

The Java programming language - Arnold, Gosling & Holmes


-------------------->3--------------------


And we all know that, exceptions clean-up the normal path, in a 
way that no other alternative seeems to do. Isn't readability 
important?



If one can understand why safe-by-default can be a moneymaker 
years from now, nothrow-by-default on the contrary would imo be a 
very costly mistake.

I spent a lot of my life optimizing programs. If there is a way 
to make a program faster, people will find it eventually. Even if 
speed is important, safety is usually a lot more important (why 
get the wrong results fast?). I've come to the conclusion that 
"you only pay for whay you use" is really wrong, since you WILL 
pay anyway for the increased bugs, lessened readability etc.

Speed shouldn't be optimized for as some kind of most desirable 
property.
This is an "appeal-to-speed" logical fallacy, since in reality 
more bugs often mean less time to optimize; you might well end up 
slower in the end.

See_also: "fast" C++ projects that don't move fast, and get 
destroyed by a Java competitor.