Mirror of forum.nim-lang.org

9413 :: Where do nimErr's comes from?

• drkameleon (orginal) [2022-08-27T10:52:01+02:00] view original

  I've been browsing through the generate sources in the Nim cache folder, and I've found many (many = I'm talking about roughly 23K lol) references and checks related to nimErr_:

  if (NIM_UNLIKELY(*nimErr_)) goto ...
  Run

  Basically, it looks as if it's sprinkled around, especially after function calls - but I doubt it if every single one of its use cases is actually needed.

  Any ideas where it's coming from and how/if I could selectively suppress some of them?

---

• drkameleon (orginal) [2022-08-27T11:07:53+02:00] view original

  OK, so... first conclusions:

  • this happens only with --mm:arc or --mm:orc
  • the vast majority of system calls (or at least a very decent % of them) seem to be followed by a nimErr_ check
  • calls to my own proc's seem to be nimErr checked as well, by default
  • setting {.enforceNoRaises.} for a proc seems to eliminate the nimErr check after a call to that specific proc

---

• guibar (orginal) [2022-08-27T11:57:25+02:00] view original

  Thas is just the "goto" exception handling, which is default for --mm:arc|orc ("setjmp" is used by default with --mm:refc). So unless you don't use exceptions, this is expected. There is the --panics:on switch which makes your program panics on "Defects" (index errors, out of mem etc…), this may remove some of this code at the price of not catching and not bubbling up defects, which are not catchable per the spec. Note that you can use --exceptions:setjmp with --mm:arc|orc.

---