Checked vs unchecked exceptions

[crimaniak via Digitalmars-d]

On Sunday, 25 June 2017 at 17:38:14 UTC, mckoder wrote:
> I am disappointed that D doesn't have checked exceptions.

Warning, Google translate is used! (sorry)

I fully support mckoder with regard to exceptions. This is a 
great advantage of Java. I think, the problem with the 
introduction of verified exceptions in D is rather psychological, 
as the authors and the community mostly came from C++. Indeed, in 
C++, the checked exceptions failed, but I think this is more a 
failure of C++ than the ideas of checked exceptions. The Java 
experience has shown that this is a powerful tool that really 
helps to write reliable programs. Most of the arguments against 
exceptions are somewhat similar to the arguments of language 
lovers with a weak dynamic typing, by which listing argument 
types seems tedious. The relevant objection is that there is a 
problem with lambdas. I think everyone who started using the 
stream API in Java 8 was faced with this problem. But who said 
that you need to exactly repeat the approach of Java? When I 
encountered this problem, I tried to write an analog of this API, 
only with support for exceptions. As a result, the root of the 
problem was easily identified. In Java, each exception type 
thrown is an additional method parameter, similar to the input 
parameters, and there are no variadic templates for them. The 
correct implementation should have some TypeTuple for all the 
types thrown. And the possibility of calculating it. The 
following thoughts should be considered as speculative, I 
understand that these ideas will not be accepted.
Take for start the system adopted in Java. Now add 'throws auto'. 
This does not mean 'throws Exception'! This means that the 
compiler must determine what exceptions this method or function 
throws. Now add a default - all functions where there are no 
throws are treated like 'throws auto'. What does this give us? 
The old code without throws continues to work, since exceptions, 
except for intercepted ones, successfully pop up to main() and 
are caught by runtime. But as soon as the author began to denote 
throws or nothrows, he gets all the benefits of the Java 
exception system. In addition, if the lower layer has changed, 
the intermediate layers that delegate the exceptions above do not 
need to be rewritten, only the code that deals directly with the 
exception processing and declares it with throws or nothrows will 
be affected. (I think that you should not abuse this, libraries 
that are supplied as a separate product should still encapsulate 
the underlying exceptions in their own).

In addition, now the specification of 'throws A, B, C' lowered to 
'throws ExceptionTypeTyple! (A, B, C)'. What does it give? We 
easily write templates that work with functions with any number 
of types of throws exceptions, and this can be handled according 
to the same rules as the other template parameters of the method.