omit assert under `--optimize`; introduce`@check` macro?

[StefanKarpinski]

People often use @assert in their code to check that functions are being used correctly. It's typical in other systems to eliminate assertions under higher optimization levels. Should we do that under --optimize? If assertions are ignored (compiled to no-ops) but also used to check correct usage – as opposed to checking the correctness of internal logic – then this can accidentally introduce a dangerous lack of argument checking. So perhaps we should introduce a @check macro that is not eliminated by --optimize and is intended for checking usage as opposed to internal correctness.

[toivoh]

+1

[JeffBezanson]

+1 to removing asserts, but I'd prefer if statements and throw to @check. A one line macro makes it harder to specify what type of exception to throw, and I think @check and @assert will be easy to confuse.

[StefanKarpinski]

People like just writing @assert size(A,2) == size(B,1) and having the error message automatically generated for them – that's a huge part of the reason people use @assert for this kind of thing even though it's not really right.

[JeffBezanson]

Fair enough. But what would we throw? ArgumentError? ErrorException?

[StefanKarpinski]

ErrorException seems like the reasonable default. If you want to do something more specific, just do a check and throw like normal. This is a feature for hastily written code.

[ViralBShah]

AssertException?

[jakebolewski]

assert now throws an AssertionError in 0.4.

[JeffBezanson]

It will probably have to be an ErrorException. You don't want a special type of exception just for using @check; it should be a shorthand for some routine kind of checking like argument checking.

[jakebolewski]

I'm struggling to see the value in this proposal, does this mean that "library" code will have assertions which can not be turned off and user level code will have @check assertions that can? To me if a library is using assertions to check internal consistency of arguments / values that library is poorly designed, why can't it throw a proper Exception instead? I feel with this proposal that you will have a mix of assertions / checks in user and library code which will be a mess.

[JeffBezanson]

Read it again; @assert could be removed, but @check would be a shorthand for error checking (not assertions) that can't be removed.

[jakebolewski]

@check seems too convenient. If users are writing library code that contains @checks how do you recover from an error when you have no clue where it was thrown or what condition led to it being thrown. This will be like generic error() messages on steroids.

Being able to turn @assertions off seems worthwhile.

[StefanKarpinski]

The alternative is people misusing @assert or not error checking at all, not writing better error checking.

[ivarne]

We already have one concept for turning off correctness tests with the @inbounds macro, and a runtime flag. We should extend that, rather than introducing a new concept.

[ivarne]

Ref #7799.

To elaborate: Bounds checking and assertions are both checks that are written in order to ensure that if the caller of a function makes a mistake, you get an exception instead of data corruption. Some code might be written with the assuption that assertions/bounds checks are on, while other code does the checking before calling the function.

A global flag to turn theese sanity checks on and off, is great for debugging, and performance testing. For real programs though, I'd want to have them on by default, and use some sort of signaling at the call site to disable them for specific regions where I can verify that the conditions are true and that the performance is critical.

I'm not qualified to talk about implementation, but the only way I can really see this work is to have a Boolean parameter to all functions that tells if it was called in a assertion free context (or a bitmask style enum to have finer granularity, but I can't imagine when you'd want to disable bounds checks, but not assertions)