On 06/15/2016 07:13 PM, tsbockman wrote:
Standardizing the error handling methods is also important for other
interoperability-related reasons:
* If every third-party library designs a different error handling
method,
people writing applications that depend on many libraries will
have to
study the `checkedint` error signaling of each one, and make sure
that
their code which interacts with each library knows how to detect and
respond to its particular signaling mechanism.
My design for `checkedint` reduces the number of
`checkedint`-specific
signaling methods that need to be studied down to one (the sticky
flags
policy). The other two policies are just using D's standard error-
handling facilities, and don't require any user intervention anyway,
unless you want to catch the exception for some reason.
Even the sticky flags policy is only of concern for `nothrow
@nogc` APIs,
which I suspect in practice will mostly mean game libraries.
* The relative simplicity of my policy set has allowed me to
arrange them
into a strict linear hierarchy, so that the results of mixing
policies
is predictable and safe.
I don't agree with this. On the face of it, three built-in policies
solve the matter of interoperability: if you want interop, use one of
those. Done. But interop is not a reason to preclude any flexibility. --
Andrei
