Versioned std.exception.bailOut()?
Jonathan M Davis
jmdavisProg at gmx.com
Fri Jun 15 10:47:15 PDT 2012
On Friday, June 15, 2012 19:31:58 bearophile wrote:
> Jonathan M Davis:
> > It's the fact that enforce is lazy which prevents inlining
> > (which really does
> > need to be fixed or enforce is going to continue to be a
> > performance problem).
>
> Then my "solution" solves nothing. Thank you Jonathan.
>
> > However, this suggestion is clearly bad, because it's
> > suggesting turning an
> > exception into an assertion, which is _very_ broken thing to
> > do. Assertions
> > and exceptions are two _very_ different things and should be
> > treated as such.
>
> enforce() sometimes is used as an assert you can't disable (as in
> Nullable.get, I think). So maybe such cases are better handled
> introducing two levels of asserts, "light asserts" and "strong
> asserts".
No. enforce and assert are fundamentaly different. One is used for throwing an
exception, which indicates an error that occurs while running the program,
whereas the other one throws an AssertError in non-release mode, which
indicates a bug in the program. enforce should be used purely for error
handling, and assert should be used purely for checking the validity of your
code.
Pretty much the only case where it's really a question of whether one or the
other should be used is when determining whether a function should be using
design-by-contract or defensive programming. If it's design-by-contract, then
failing the condition of the contract is a bug, and an assertion is used. If
it's defensive programming, then the function treats its parameters as if they
were user input, verifies them, and then throws if the conditions aren't met,
thereby indicating an error condition to the caller. The choice between the
two is a matter of whether the function treats its input as user input or not.
In the case of std.typecons.Nullable, it's treating its state as something
relating to the program's input such that it is not necessarily a bug in the
program if it attempts to get Nullable's value when it's null. So, the
programmer does not need to check whether the Nullable is null or not before
using it if they don't want to. If it were using assert, then it would be
saying that programmer must guarantee that its state is not null before its
value is fetched, or it's a bug. The two approaches mean fundamentally
different things to how Nullable is designed and used.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list