Is the warning about `@assert` or `AssertionError`?

General Usage
1

I use the @assert macro all over the place, including inside struct constructors to make sure my types are following the restrictions they’re supposed to.

The documentation on @assert says it is the preferred syntax for writing assertions, but it also warns that “An assert might be disabled at various optimization levels”. The documentaiton on AssertionError does not have this warning.

My question is, is the warning about the macro or the AssertionError itself?

If the warning is about how the macro is implemented, I am going to make a copy of the macro definition and just give the macro my own name. Otherwise I’ll need to stop using AssertionError altogether.

I asked this question in the thread below but didn’t get an authoritative answer. Hoping someone can help.

2

@assert “should” be used only for debugging purposes, and is allowed to be disabled (a complete no-op) at any optimization level. Although in all released versions it is not disabled*

Unfortunately the messaging here has possibly not been as firm as it should have been, so you are certainly not alone in having used @assert for the purpose of input validation that should be always on. Nonetheless, it’s not “correct” usage, and I would recommend either switching to ArgCheck.jl or throwing custom errors directly

* this may change by 1.12, see :

2 Likes
3

Thanks for the response and for the link. I’m not sure it answers my question though. Can I use AssertionError in my custom errors or is it this that is disabled during optimization?

4

The docs for AssertionError seems to leave open the exceptional cases where it’s thrown by something other than @assert, but it’s not actually clear to me if it’s meant for it. For example, the Core.typeassert (sugar syntax via :: in right handexpressions) asserts the type of an instance, and it throws a TypeError instead. If you only need to throw runtime errors when instances aren’t the right type, I’d use that instead.

5

Yes you can use AssertionError, but you can also create your own error that conveys the necessary information.

I would recommend against reusing an internal compiler error for your own code.

3 Likes
6

TypeError is internal? It, typeassert, and the syntax :: are all documented for general use.

7

typeassert and :: are documented for general use. It’s also documented that they produce a TypeError, but the structure of that TypeError may change.

I would be rather surprised if I received a TypeError from something other than typeassert.

1 Like
8

TypeError is also separately documented to have a format you can customize for different function names or contexts. It also occurs when keyword arguments don’t have the declared types:

julia> range(0, 1; length = 1.1)
ERROR: TypeError: in keyword argument length, expected Union{Nothing, Integer}, got a value of type Float64
...

That’s obviously different from a typeassert’s message:

julia> 1::String
ERROR: TypeError: in typeassert, expected String, got a value of type Int64
...