[R] get caller's name

Luke Tierney luke-tierney at uiowa.edu
Fri Feb 4 19:02:55 CET 2011


The options showWarnCalls and showErrorCalls may also help --
they can be use do enable automatic printing of a call stack
summary. From ?options:

      ‘showWarnCalls’, ‘showErrorCalls’: a logical.  Should warning and
           error messages show a summary of the call stack?  By default
           error calls are shown in non-interactive sessions.

Best,

luke


On 02/04/2011 10:09 AM, William Dunlap wrote:
>> -----Original Message-----
>> From: r-help-bounces at r-project.org
>> [mailto:r-help-bounces at r-project.org] On Behalf Of Duncan Murdoch
>> Sent: Friday, February 04, 2011 6:03 AM
>> To: Ernest Adrogué
>> Cc: r-help at stat.math.ethz.ch
>> Subject: Re: [R] get caller's name
>>
>> On 03/02/2011 10:27 AM, Ernest Adrogué wrote:
>>> Hi,
>>> Suppose a function that checks an object:
>>>
>>> stop.if.dims<- function(x) {
>>>     if (! is.null(dim(x))) {
>>>       stop("cannot handle dimensional data")
>>>     }
>>> }
>>>
>>> This would be used by other functions that can only work with
>>> dimensionless objects. The problem is the error message
>> would need to
>>> include the name of the function that called stop.if.dims,
>> so that the
>>> user knows which function got an argument that was incorrect.
>>>
>>> How do I do this? Or maybe there is another way...
>>
>> I see you have the answer you wanted, but I'd suggest you don't need
>> this:  the user should just use traceback() after the error
>> to see the
>> full call stack.  Perhaps it's not the caller that's the problem, but
>> the caller of the caller...
>>
>> Duncan Murdoch
>
> stopifnot() deals with the problem by arranging for the
> error reporting mechanism not to say what function the
> error comes from.  If you are in the know, not seeing
> "Error in someFunction(arg):" in the error might motivate
> you to call traceback().  If you are not in the know, it
> just frustrates you.
>
>     R>  myFunc<- function(x) stopifnot(all(x>0))
>     R>  myFunc(-pi)
>     Error: all(x>  0) is not TRUE
>     R>  traceback()
>     3: stop(paste(ch, " is not ", if (length(r)>  1L) "all ", "TRUE",
>            sep = ""), call. = FALSE)
>     2: stopifnot(all(x>  0))
>     1: myFunc(-pi)
>
> In S+ stopifnot() uses eval(call("stop", message), sys.parent())
> to make the error message appear to come from the caller of
> stopifnot().  The initial message is clearer but the traceback
> more confusing:
>
>     >  myFunc<- function(x) stopifnot(all(x>0))
>     >  myFunc(-pi)
>     Problem in myFunc( - pi): all(x>  0) is not TRUE
>     Use traceback() to see the call stack
>     >  traceback()
>     8: eval(action, sys.parent())
>     7: doErrorAction("Problem in myFunc( - pi): all(x>  0) is not TRUE", 1000)
>     6: stop("all(x>  0) is not TRUE")
>     5: eval(call, sys.parent())
>     4: stopifnot(all(x>  0))
>     3: myFunc( - pi)
>     2: eval(expression(myFunc( - pi)))
>     1:
>     Message: Problem in myFunc( - pi): all(x>  0) is not TRUE
>
> If I try the eval(call("stop",message), sys.parent()) trick
> in R the error is reported as being from eval():
>     >  myFunc(-pi)
>     Error in eval(expr, envir, enclos) : all(x>  0) is not TRUE
>
> S+'s error handler has some logic so that a stop() called from
> eval() is reported as being from the frame that eval is evaluating
> in.
>
> It might be nice to be able to tell stop(), warning(), and message()
> to pretend they were called from somewhere other than where they
> were actually called from.  Falling back on traceback() doesn't
> help with warnings and messages.  Being able to put standard messages
> like 'x not a matrix' into utility functions is handy, but it makes
> it hard to track down the problem.
>
> Bill Dunlap
> Spotfire, TIBCO Software
> wdunlap tibco.com
>
>
>>
>> ______________________________________________
>> R-help at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>>
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

-- 
Luke Tierney
Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:      luke at stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu



More information about the R-help mailing list