Description Usage Arguments Value Extra data Exceptions are part of your API See Also Examples
The generated Exception
object is a subclass of
condition
. It describes an anomalous event and is intended to
be the basis of a hierarchy of exception classes. Exceptions are signaled by
calling stop
, warning
, or message
on an Exception
or Exception
-derived object and can be caught
individually or in groups using try/catch signal handlers. Exception
objects inherit the message
and call
fields from
condition
and add a package
field that
describes what package this exception event happened in. They also add any
unused argName= value
arguments as extra data, storing
this inside the exception object for internal use.
1 2 3 4 5 | Exception(message = "An Exception occurred.", call = sys.calls(),
package = packageName(), ...)
## S3 method for class 'Exception'
conditionMessage(c)
|
message |
The message associated with the exception. By default this is |
call |
The call or call stack associated with the exception. By default this is
the list returned by calling |
package |
The package where this exception is generated; tries to guess this by
default. When not called from within a package, this will likely be
|
... |
Additional arguments defining |
c |
An excepetion object. This parameter is called "c" to be compatible with the underlying S3 object "condition" class. |
Exception
returns an Event
object, which is an object
of class c("Exception", "condition")
describing some problematic
event, usually signaled from within a package e.g. with stop
.
conditionMessage
called on a Exception
object returns the message
associated with that exception, with the package
of the exception
prepended.
Data provided through extra arguments are accessible by treating an
Exception
as a list. This is intended to be used only internally in
the package or script that signaled the Exception
. If data is
included for use by handlers in external code (from other packages or
users), S3 accessors should be defined. Similarly, external code should
never need to include extra data in exceptions for use by internal code.
Custom exception generating functions with appropriate arguments should be
exported. See extendException
.
If exceptions are visible to users they are part of that functions public
API just like arguments are. Any exception that a function signals by e.g.
stop
, warning
, message
, etc, that
are not handled within that function are visible to users. These should be
clearly documented and generally can be changed only in a
backward-compatible manner. User code that catches exceptions will depend
on them being thrown with the same class name and having both the same
parent classes and the same accessible data, if any. Defining custom
exception classes and using S3 accessors for any data makes this easier.
condition, conditionMessage, conditionCall, exceptionPackage, tryCatch
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | e <- Exception()
conditionMessage(e)
conditionCall(e)
exceptionPackage(e)
e <- Exception( "Extra data included", x=1, y=2, z=list(A=1, B="two") )
x <- e$x
y <- e$y
z <- e$z
## Not run:
stop(Exception( "Oops, that didn't work." ))
# Convert a fatal Exception into a warning.
e <- Exception( "Lying about the package", package="NotMine" )
tryCatch( stop(e), Exception= function(e) {warning(e)})
## End(Not run)
|
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.