I would expect the compiler to warn about a possible division by zero error but it compiles just fine. When calling division(3, 0), it of course raises DivByZeroError at runtime.
To be honest, the explanation at https://nim-lang.org/docs/manual.html#effect-system confuses me. For example, without an example I have a hard time understanding "Every expression of some proc type within a call that is not a call itself (and not nil) is assumed to be called indirectly somehow and thus its raises list is added to p's raises list.".
From the list of inference rules I would assume that "For every other call the analysis can determine an exact raises list." would cover my toy example.
What am I missing here?
DivByZeroError extends ArithmeticError which extends ` Defect <https://nim-lang.org/docs/system.html#Defect>`_. This is a different type from ` CatchableError <https://nim-lang.org/docs/system.html#CatchableError>`_, which is what {.raises.} tracks at the time being, with the added problem that Defects can still be caught.
There are multiple issues open on this: about Defect being caught, RFC about Defects not being tracked, issue about Defects not being tracked
What am I missing here?
What the spec tries to say is that raise statements are tracked, nothing more. Builtins like div are not considered to raise. And with --panics:on they do not raise indeed.