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.
