Bug 14770 - traceback print stack not of the failed call but of the preceding one
traceback print stack not of the failed call but of the preceding one
Status: RESOLVED FIXED
Product: R
Classification: Unclassified
Component: Language
R 2.14.1 patched
x86_64/x64/amd64 (64-bit) Linux
: P5 enhancement
Assigned To: R-core
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-02 19:17 UTC by Simon Anders
Modified: 2012-01-03 14:52 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Anders 2012-01-02 19:17:38 UTC
Observe in the following example session how the stack trace printed by 'traceback' is in all but the first instance not the trace of the current one but of the preceeding one. I alternate between calls to two error-signaling functions, called 'foo' and 'bar'. Note the inconsitency between call, error message and stack trace in all but the first call: If 'foo' is called, an 'Error in foo()' is announced, but the trace back contains 'bar', which was called before.

> foo <- function( ) stop( "foo" )
> bar <- function( ) stop( "bar" )
> options( error = traceback )
> foo()
Error in foo() : foo
No traceback available 
> bar()
Error in bar() : bar
2: stop("foo")
1: foo()
> foo()
Error in foo() : foo
2: stop("bar")
1: bar()
> bar()
Error in bar() : bar
2: stop("foo")
1: foo()
> sessionInfo()
R Under development (unstable) (2012-01-01 r58033)
Platform: x86_64-unknown-linux-gnu (64-bit)

locale:
 [1] LC_CTYPE=en_US.utf8       LC_NUMERIC=C             
 [3] LC_TIME=en_US.utf8        LC_COLLATE=en_US.utf8    
 [5] LC_MONETARY=en_US.utf8    LC_MESSAGES=en_US.utf8   
 [7] LC_PAPER=C                LC_NAME=C                
 [9] LC_ADDRESS=C              LC_TELEPHONE=C           
[11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C      

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base
Comment 1 Duncan Murdoch 2012-01-02 19:48:54 UTC
This is the way it is designed.  At the time the error handler is called, the traceback hasn't been created, so you see the previous traceback.

I haven't marked this as closed, but changed it to an "enhancement", because it would be useful to do what you were trying to do.

I think what is needed is a user-visible function to create the traceback.

I've assigned it to myself, but I don't think I'll get to it for at least a month; if someone else wants to take it on, please go ahead.
Comment 2 Simon Anders 2012-01-02 23:43:38 UTC
Thanks for the explanation. I should have noticed that myself, given the message "no traceback available" in the first instance. And thanks for taking is as an enhancement suggestion.
Comment 3 Duncan Murdoch 2012-01-03 14:52:34 UTC
The function was already there, just not exposed, so this was easier than I thought.  traceback() now optionally displays a current traceback, rather than one from the last error.