Hello, It is continue of the https://forum.nim-lang.org/t/8978 and https://forum.nim-lang.org/t/9765
After digging of the some code I found that IndexError was always inherited from Defect. Probably it is my personal problem that it was unexpected, that is why I want to clarify it for me:
1) unrelated to panics:on or off, Nim does bounds-check, but if we do manual bound-check also, doesn't it mean that we do double-check?
let v = "abc"
let i = 3
if i notin v.low..v.high: # first check
echo "error"
echo v[i] # second check
3) I dev in rust and go-lang with panics without any problems, but which benefits does it give in Nim? If it is performances, then for the repo https://github.com/shish/rosettaboy/pull/137#issue-1589314194 I have the following results:
danger+lto+gcc:
> ./rosettaboy-off -H -S -t -p 10 ../opus5.gb
Emulated 21572 frames in 10.00s (2157fps)
> ./rosettaboy-on -H -S -t -p 10 ../opus5.gb
Emulated 20900 frames in 10.00s (2089fps)
release+lto+gcc:
> ./rosettaboy-off -H -S -t -p 10 ../opus5.gb
Emulated 21007 frames in 10.00s (2100fps)
> ./rosettaboy-on -H -S -t -p 10 ../opus5.gb
Emulated 21407 frames in 10.00s (2140fps)
3. I dev in rust and go-lang with panics without any problems, but which benefits does it give in Nim?
Same benefit as it does for Rust, the type system becomes more effective at distinguishing between "expected errors you should handle" and "bugs". Whether that distinction is all that worthwhile for the usual "the web service needs to keep running anyway" use case is still up for debate.
To closed the thread.
I think that my initial problem and reaction came from the bad code in parsing like split()[idx] and it is just forced me to rewrite it better way with scanf after it I did not find any important [idx] and which fails - definitely bug and have to be fixed - thank you for explanation
But the rest of the question: how to catch everything is still actual.
Example: I like asciigraph lib but it fails with IndexDefect sometimes, but the chart is not critical for my app at all. to fix other libs is not an option of course :)
how to catch everything is still actual.
By using try: except <nothing here>:
I think that you are right, but it does not mean that it will be 100% ideal and better to not close the app anyway - I think it is a bit another question
And one more question: I started to write except CatchableError, Defect everywhere just to supress the warning, that is why I think it would be better to disable it for panics:off
I think it is the same like to suggest to show all mm:none or arc warnings for mm:org. But in case to show that problem is possible here
But my idea to show the error, not to hide, because the exect Catchable, Defect will hide the problem, that is why I think it is better to show it when you really hit panics:on - oh, what is it, instead of: wth is it, and after few hours: ah, someone suppressed expect with Defect
FWIW, I use a template to catch both CatchableError and Defect, with a check in the module that makes building with options that would make this invalid a compile error.
#
# catchAll template to replace unqualified try: except: blocks
#
# Check compile options allow catching common Defects
when defined(nimPanics) or
not compileOption("objChecks") or
not compileOption("fieldChecks") or
not compileOption("rangeChecks") or
not compileOption("boundChecks") or
not compileOption("overflowChecks"):
{.error: "Cannot catchAll when panics are on or checks are disabled".}
# Warn if floating point errors aren't caught
when not not compileOption("floatChecks") or
not compileOption("nanChecks") or
not compileOption("infChecks"):
{.warning: "catchAll included but floating point checks not enabled".}
template catchAll*(body:untyped,handler:untyped) =
## try a block of code, catching both CatchableError and Defect
## can't safely use this if you need to compile with panics:on or -d:danger
try:
body
except CatchableError, Defect:
handler
## example usage
# var
# arr = [9]
# o = 5
#
# catchAll:
# echo arr[o]
# do:
# echo getCurrentExceptionMsg()
PS: Just compiled jsony - few pages just of the warning. I am afraid that 80% of libs will supress it one or another way.
This warning should be opt-in indeed.
Btw you can avoid such bugs by ...testing your software thoroughly.
And once you do that you might as well through away all these silly .raises annotations cough.
Don't get me wrong, static typing is still great but there is an optimal amount of it, "the more the better" rarely applies in reality.
After looking into the PR https://github.com/treeform/jsony/pull/58
I suppose that the problem is in "default" meaning of bare-expect. If the target to move into panics:on some day - it is good, but in the case default expect should be like expect CatchableErrors now, but without any "CatchableErrors" extra noise.
now => ok with panics:ok