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

**URL:** <https://discourse.julialang.org/t/is-the-warning-about-assert-or-assertionerror/110613>\
**Category:** General Usage\
**Created:** [February 22, 2024, 11:36pm UTC](https://discourse.julialang.org/t/is-the-warning-about-assert-or-assertionerror/110613 "2024-02-22T23:36:31Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![sadish-d](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sadish-d/32/48058_2.png) [@sadish-d](https://discourse.julialang.org/u/sadish-d)\
**Post date:** [February 22, 2024, 11:36pm UTC](https://discourse.julialang.org/t/is-the-warning-about-assert-or-assertionerror/110613/1 "2024-02-22T23:36:31Z")

</div>

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.

> [@@assert: what is the proper tool?](https://discourse.julialang.org/t/assert-what-is-the-proper-tool/36217/):
>
> Apparently @assert can be elided by the compiler for some optimization level. What is the recommended easy and fool-proof ways of asserting program behaviours?

---

<div class="post-metadata">

**Author:** ![adienes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/adienes/32/37459_2.png) [@adienes](https://discourse.julialang.org/u/adienes)\
**Post date:** [February 22, 2024, 11:43pm UTC](https://discourse.julialang.org/t/is-the-warning-about-assert-or-assertionerror/110613/2 "2024-02-22T23:43:31Z")

</div>

`@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 :

> <https://github.com/JuliaLang/julia/pull/53404>
>
> This PR adds a new flag to control when a "julia specific" debug mode is active.… When the debug mode is active the following happens:
> \- The \`@assert\` macro is active
> \- The \`isdebug\` function returns \`true\`.
> 
> Currently, the \`--debug\` has three options:
> \- \`"yes"\`: debug mode is active in scripts and packages
> \- \`"script"\`: debug mode is active in scripts (default)
> \- \`"no"\`: debug is not active anywhere
> 
> The debug mode is a "compile time option" meaning that it will recompile packages if it changes.
> 
> There are still many open questions regarding this:
> 
> \- Should this instead use \`-g\` and coexist with the current behavior of \`-g\` or should it just steal it?
> \- Are the defaults here reasonable?
> \- When running \`Pkg.test\` should assertions be enabled everywhere or only in the tested package etc?
> \- Will it be expected that people run their tests under both debug and normal mode?
> \- Should \`--debug\` has any influence on \`--check-bounds\`?
> \- Probably many more
> 
> Subsumes https://github.com/JuliaLang/julia/pull/37874
> 
> Ref https://github.com/JuliaLang/julia/pull/41342, https://github.com/JuliaLang/julia/pull/53223

---

<div class="post-metadata">

**Author:** ![sadish-d](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sadish-d/32/48058_2.png) [@sadish-d](https://discourse.julialang.org/u/sadish-d)\
**Post date:** [February 22, 2024, 11:54pm UTC](https://discourse.julialang.org/t/is-the-warning-about-assert-or-assertionerror/110613/3 "2024-02-22T23:54:17Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [February 23, 2024, 1:09am UTC](https://discourse.julialang.org/t/is-the-warning-about-assert-or-assertionerror/110613/4 "2024-02-23T01:09:57Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![vchuravy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vchuravy/32/8_2.png) [@vchuravy](https://discourse.julialang.org/u/vchuravy)\
**Post date:** [February 23, 2024, 1:29am UTC](https://discourse.julialang.org/t/is-the-warning-about-assert-or-assertionerror/110613/5 "2024-02-23T01:29:59Z")

</div>

> [@sadish-d](#):
>
> Can I use `AssertionError` in my custom errors or is it this that is disabled during optimization?

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

> [@Benny](#):
>
> 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.

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

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [February 23, 2024, 1:31am UTC](https://discourse.julialang.org/t/is-the-warning-about-assert-or-assertionerror/110613/6 "2024-02-23T01:31:47Z")

</div>

`TypeError` is internal? It, `typeassert`, and the syntax `::` are all [documented](https://docs.julialang.org/en/v1/manual/types/#Type-Declarations) for general use.

---

<div class="post-metadata">

**Author:** ![vchuravy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vchuravy/32/8_2.png) [@vchuravy](https://discourse.julialang.org/u/vchuravy)\
**Post date:** [February 23, 2024, 3:10am UTC](https://discourse.julialang.org/t/is-the-warning-about-assert-or-assertionerror/110613/7 "2024-02-23T03:10:48Z")

</div>

> [@Benny](#):
>
> `TypeError` is inter

`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`.

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [February 23, 2024, 3:22am UTC](https://discourse.julialang.org/t/is-the-warning-about-assert-or-assertionerror/110613/8 "2024-02-23T03:22:10Z")

</div>

[`TypeError`](https://docs.julialang.org/en/v1/base/base/#Core.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
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
julia> 1::String
ERROR: TypeError: in typeassert, expected String, got a value of type Int64
...

```