They're catchable, but you're not supposed to catch them without a really good reason.
Relevant issue: https://github.com/nim-lang/Nim/issues/11776
They're catchable, but you're not supposed to catch them without a really good reason.
Interesting! Does this mean - to stay with DivByZeroDefect - that I should always test for the denominator to be not zero _before I do the division instead of using try... except?
DivByZero is literally not catchable. This is a check that Nim does before actually dividing when checks are on.
If you divide by zero your CPU will send a signal and your OS will abort your program with SIGFPE and you cannot do anything about it.
No, I don’t think so. This works (without --panics:on: of course):
var x = 0
try:
echo 1 div x
except DivByZeroDefect:
echo "ok"
Wow, this is a pretty new paradigm for me: Coming from Python I usually obeyed EAFP ("easier to ask for forgiveness than permission") and only in time critical situations I optimised code against it.
But, ok, LBYL (look before you leap) sounds good to. :-)
If you use vector instructions:
If you use assembly:
For desktop computers I didn't come across any other hardware-induced crashes.
few such cases
SIGSEGV? you usually can't tell what state your application is in after one of these, so you can't reliably raise or handle it.
Options like --panics:on and exceptions:goto create a different dialects of the language that libraries you use may or may not support.
Whether or not something is a Defect is somewhat arbitrary in that each type has its own rules - for example, var i = @[1]; echo i[1] raises a Defect - var t: Table[int, int]; echo t[1] raises a catchable - you'll need to read the documentation for every function you call, and quite often its implementation, to find out - there's usually no direct technical reason for things being Defect - it's rather a style / design choice.