R help - Mar 2012 - tryCatch interferes with traceback(), debugger(), dump.frames()....

I want to use tryCatch, but tryCatch seems to obscure important things I
need for debugging.

For example, say I am working with an SQLite database, and have written
this function:

debugThisFunction <- function(dbfile) {
  require(RSQLite)
  drv <- SQLite()
  conn <- dbConnect(drv, dbfile)
  tryCatch({

    dbBeginTransaction(conn)
    tryCatch({

      for (i in 1:10) {
        somethingWhichCrashesSometimes()
      }

    }, error = function(e) {dbRollback(conn); stop(e)})
    dbCommit(conn)

  }, finally=dbDisconnect(conn))
}

somethingWhichCrashesSometimes <- function() {
  v <- runif(1)
  y <- runif(v*10-3)
}

options(error=dump.frames)
debugThisFunction("test.sqlite")

I've done the proper thing and used exceptions for resource management, so
that I always finish by closing the connection and so that I roll back the
transaction in case of errors.

However, when there is a problem, I need to debug it. Normally when I see
an error I would invoke debugger() or backtrace() and see where in the code
the error came from, check what the value of 'v' was that occasioned the
error, and find the problem. In this case, debugger() and traceback() point
to stop(e), not to the call to runif(), which makes it harder to figure out
what went wrong.

In most languages-featuring-exceptions I have used, there is something like
"rethrow" which propagates the original error _including the stack
trace_
after you are done cleaning up in your error handler. Actually in my
opinion that is a big reason why exceptions are a language feature in the
first place - to propagate out debugging information while allowing you to
clean up. So I am confused why tryCatch ends up obscuring the debugging
information. How can I use it in a way that dump.frames() or retrace() or
some equivalent points me to the right spot?

Peter Meilstrup

	[[alternative HTML version deleted]]