Mirror of forum.nim-lang.org

13990 :: In Nimony, should DB-resource destructors raise, or should cleanup stay explicit?

• planetis (orginal) [2026-06-20T22:08:34+02:00] view original

  Hello, I’m building a small SQLite-backed library in nimony and I’m stuck on the cleanup model for owned DB resources.

  The core problem is that some cleanup operations can fail:

  • sqlite3_finalize(stmt)
  • sqlite3_close_v2(db)
  • transaction rollback/commit paths

  So I’m trying to choose between:

  1. Destructors own cleanup, but then errors are discarded.
  2. Explicit cleanup in finally / close(), so errors can be checked normally.

  
  type
    DbHandle = object
      conn: sqlite3.DbConn
    
    StmtHandle = object
      stmt: sqlite3.Stmt
  
  proc `=destroy`(x: DbHandle) =
    discard sqlite3_close_v2(x.conn)   # can fail, but destructor can't report it
  
  proc `=destroy`(x: StmtHandle) =
    discard sqlite3_finalize(x.stmt)    # same problem
  Run

  If I avoid destructors, cleanup becomes explicit:

  
  proc close(x: DbHandle) {.raises.} =
    checkSqlite(sqlite3_close_v2(x.conn))
  
  iterator rows(x: sink StmtHandle): Row =
    try:
      while step(x.stmt) == SQLITE_ROW:
        yield decode(x)
    finally:
      checkSqlite(sqlite3_finalize(x.stmt))
  Run

  That preserves error reporting, but loses RAII-style cleanup.

  So my question is: what’s the recommended pattern in Nim/nimony for database libraries when cleanup itself can fail? Should destructors be allowed to raise, or is explicit close/finally the preferred idiom? I am torn with this one.

---

• Araq (orginal) [2026-06-20T23:07:27+02:00] view original

  Do both, destructors do cleanup and swallow errors (or set localErr?) and offer a flush operation that can raise/report errors.

---

• filcuc (orginal) [2026-06-21T00:03:21+02:00] view original

  Doing both implies handling in every api the state of the resource (ie if closed …). If you stick only on costructor and destructor you api is more safe with the cons that user must handle correctly the lifetime of the handle if he/she want to have some predictability on the resource freeing. The main point is if you want your handle to be used by multiple threads or not. In case you want thread safety and you want to add an explicit close method remember that you need to design some read/write lock on your handle in order to not close it while a thread is using it.

---

• planetis (orginal) [2026-06-21T13:25:23+02:00] view original

  Thanks both, you mention important points to consider.

---