Hello world. Here is my code:
var
arr = [9]
o = 5
try:
echo arr[o]
except:
echo "Failed !"
echo "End of program"
The compiler warn that "bare except clause is deprecated", and suggest that I write except CatchableError instead. But when I follow this recommendation, the try - catch block do no longer prevent the error from propagating. Is that normal ?
@xigoi It is clear, but a bit clear how to live with it.
Does it mean - that we have to check range manually? Or maybe we have to catch IndexError too near Catchable
Does it mean - that we have to check range manually?
Yes, in cases where it is reasonably possible that the index may be out of range.
The difference with stuff like KeyError is that when we search a table for a key and don't find it, there's no fast "default" behavior to fall back on, so we can use catchable errors. However for things like out of bounds memory access or overflows, we would normally get silent or signal errors that we can't easily deal with. I'm guessing defects are supposed to be a more structured, informational representation of these situations.
I don't like the exception model of Nim, when I want to write an server program, which process data every cycle, there is possible sometime the program don't do good because of we don't know what will the input data be, so I need to catch all exception, regardless of Defect or Error or SystemError, I want to skip this cycle and do the next cycle.
This is a criticsm that I sympathize with, and there are plans to tweak these rules. I'm preparing the documents.
Note: My reply refers to index checking only. And only to single element indexing, not slices.
From the beginning of Nim array/seq index checking was only supposed to be a debugging aid. Correctly written code should not depend on it and the past the release mode turned off the bounds checks. Now only the "danger" mode turns it off.
The fact that you can "catch" the IndexError for builtin types at all is in order to make unit testing easier. It's not a general purpose mechanism.
Now, should your code style change and not contain indexing errors after a debugging session? Yes.
However! What does that mean in practice for you? Which idiom do you depend on that gets more cumbersome? I'm curious.
The thread gave an good example - sometimes I just want to catch any catchable _including IndexError like it was before, from the point looks like I have to add if i notin v.low..v.high: raise in many places to cover it or implement my own get(idx)
Also, I am afraid that Nim could be less friendly for high-level devs from python. I do not want to say that Nim should follow python, but it add some amount of (unnecessary for them) learning curve - how to work with indexes
For example here: https://github.com/inv2004/ttop/blob/main/src/ttop/procfs.nim I see about 41 lines with [idx]
The thing I do not like about the code:
It is just suppress the warning about bare-except, but if I try to compile with --panics:on another day - the warning will be still suppressed and I will find the program fails. I think I would prefer to see the warning only if p:on.
The same example is about --m:none - if have a lot of errors, but you do not see the warning "just in case" if you use orc. With the IndexDefect - it looks like that it is enabled for "just in case" for p:off.
I would split devs into two teams about the problem:
My personal opinion - I think that the second way is better - I like that I can write on Nim easy and even to promote it to less-experienced python-colleagues, but _if I can do perf and any unsafe I want, _but
It is just fast and rundom idea how I see it would be ok from my point-of-view
@Araq
The indexErrors:on is about v2, but looks like it will go into many libs instead of automatic switch by p:on|off, that if why probably safe [] and unsafe[] looks a bit better
@arnetheduck1h I agree, it is v1 I mentioned, except that probably safe [] should be default, but {} is not. But I do not think that it is good if everyone will write own {} implementation
On another hand I changed my mind a bit. Because it means that code will have [] and {} but it does not allow to optimize it with just one flag like "-d:danger". Probably I am wrong, but I never expect that "-d:danger" works out-of-the-box on any code