If you run this code playground
type O = ref object
some: int
var o: O
try:
echo o.some
except:
echo "failed"
You'll get
SIGSEGV: Illegal storage access. (Attempt to read from nil?)
Why it works that way and the except didn't caught the error?
I don't think it should be on by default, but this works great
import segfaults
type O = ref object
some: int
var o: O
try:
echo o.some
except:
echo "failed"
The not nil should catch this.
In theory, in practice nobody using it. Also, in my case the exception happens inside a third-party library.
I think such approach is wrong. Nim is not null-safe, and null errors in Nim are not rare. And it can't catch it in default configuration. Not good.
You're not supposed to "catch" bugs, you're supposed to fix them.
To elaborate on Arne's statement, one is not supposed to catch a defect, so do not catch them!
Quoting the manual:
Exceptions that indicate programming bugs inherit from system.Defect (which is a subtype of Exception) and are strictly speaking not catchable as they can also be mapped to an operation that terminates the whole process.
Take for example the following completely sensible code:
var
a: 1..3
b = 10
try:
a = b
except:
a = 3
echo a == 3
On release presently it echos true, but on danger false. Now how about we write it so it doesnt have different behaviour.
var
a: 0..3
b = 10
if b in a.low..a.high:
a = b
else:
a = 3
echo a == 3
With a minor change we've now showed intent and also cause our defect to go away(without using exception handling). Now if you are using a library and it emits a nil access error that either means you're doing something wrong, or the library has a bug and you should ether fix it or make an issue to establish that it's broken. You can use not nil annotation and also wrapnils to avoid many nil reference issues without using exception handling, a nil reference is not exceptional. You're not supposed to "catch" bugs, you're supposed to fix them.
laughs in Java