No Clocks

I always meant to do a post showing my style for writing COM programs in C++ without using smart pointers. It was an extremely clear, rigid style that guaranteed that I would not create resource leaks; basically I was simulating exception handling with macros, with exactly one “catch” per method. I don’t recall if I ever wrote that article; if I did, I guess I’ll find it while I’m porting these posts. In retrospect I no longer entirely agree with the hot take in the final paragraph. C# and F# are both perfectly usable languages that blend different coding styles. That said, I would not want to do a line-for-line rewrite of a C# program in F#, or vice-versa; that really would be unmaintainable. There was a good question in the comments about the performance of exception handling. My response was that there are two aspects to exception handling performance: What is the additional over-all burden imposed by exceptions? An interesting question, but not actually relevant to making a decision. Why? Because in the .NET framework, there is no way to “turn off” exceptions. You’re stuck with this infrastructure. If you can’t change it, there’s no reason to worry about it. If you cannot turn it off then the question is not “are exceptions fast enough in the CLR?” but rather “is the CLR fast enough?” What’s the cost of throwing one exception? This second concern I don’t care about one bit. Exceptions are, by definition, exceptional. When one of my programs gets an exception, almost always it is either doing something incredibly expensive already (in which case the cost of the throw is irrelevant) or we are going to report the exception to the user (in which case the program is going to come to a halt.) Either way, the per-throw cost is unimportant. However, I missed a trick here. There is an additional cost, which is: what is the cost not of throwing an exception, but catching an exception? The jitter generates more code in a method with a try-catch or try-finally, which means that it has less time available in its budget for optimization. And those optimizations get harder to perform because there is more complex control flow to consider. Still, I wouldn’t give up exception handling and go back to return codes. There are a number of design changes I would have liked to see in the exception system though. But that is a topic for another day.

Writing good error handling code is hard in any language, whether you have exception handling or not. When I’m thinking about what exception handling I need to implement in a given program, I first classify every exception I might catch into one of four buckets which I label fatal, boneheaded, vexing and exogenous.

Fatal exceptions are not your fault, you cannot prevent them, and you cannot sensibly clean up from them. They almost always happen because the process is deeply diseased and is about to be put out of its misery. Out of memory, thread aborted, and so on. There is absolutely no point in catching these because nothing your puny user code can do will fix the problem. Just let your finally blocks run and hope for the best. (Or, if you’re really worried, fail fast and do not let the finally blocks run; at this point, they might just make things worse. But that’s a topic for another day.)

Boneheaded exceptions are your own darn fault, you could have prevented them and therefore they are bugs in your code. You should not catch them; doing so is hiding a bug in your code. Rather, you should write your code so that the exception cannot possibly happen in the first place, and therefore does not need to be caught. That argument is null, that typecast is bad, that index is out of range, you’re trying to divide by zero – these are all problems that you could have prevented very easily in the first place, so prevent the mess in the first place rather than trying to clean it up.

Vexing exceptions are the result of unfortunate design decisions. Vexing exceptions are thrown in a completely non-exceptional circumstance, and therefore must be caught and handled all the time.

The classic example of a vexing exception is Int32.Parse, which throws if you give it a string that cannot be parsed as an integer. But the 99% use case for this method is transforming strings input by the user, which could be any old thing, and therefore it is in no way exceptional for the parse to fail. Worse, there is no way for the caller to determine ahead of time whether their argument is bad without implementing the entire method themselves, in which case they wouldn’t need to be calling it in the first place.

This unfortunate design decision was so vexing that of course the frameworks team implemented TryParse shortly thereafter which does the right thing. You have to catch vexing exceptions, but doing so is vexing. Try to never write a library yourself that throws a vexing exception. And finally, exogenous exceptions appear to be somewhat like vexing exceptions except that they are not the result of unfortunate design choices. Rather, they are the result of untidy external realities impinging upon your beautiful, crisp program logic.

You’ve got to catch an exogenous exception because it always could happen no matter how hard you try to avoid it; it’s an exogenous condition outside of your control.

So, to sum up: Don’t catch fatal exceptions; nothing you can do about them anyway, and trying to generally makes it worse. Fix your code so that it never triggers a boneheaded exception – an “index out of range” exception should never happen in production code. Avoid vexing exceptions whenever possible by calling the “Try” versions of those vexing methods that throw in non-exceptional circumstances. If you cannot avoid calling a vexing method, catch its vexing exceptions. Always handle exceptions that indicate unexpected exogenous conditions; generally it is not worthwhile or practical to anticipate every possible failure. Just try the operation and be prepared to handle the exception.

HOME: The user's ‘home’ directory. LANGUAGE: Optional. The language(s) to be used for message translations. This is consulted when needed. LC_ALL: (etc) Optional. Use to set various aspects of the locale – see Sys.getlocale. Consulted at startup. MAKEINDEX: The path to makeindex. If unset to a value determined when R was built. Used by the emulation mode of texi2dvi and texi2pdf. R_BATCH: Optional – set in a batch session, that is one started by R CMD BATCH. Most often set to "", so test by something like !is.na(Sys.getenv("R_BATCH", NA)). R_BROWSER: The path to the default browser. Used to set the default value of options("browser"). R_COMPLETION: Optional. If set to FALSE, command-line completion is not used. (Not used by the macOS GUI.) R_DEFAULT_PACKAGES: A comma-separated list of packages which are to be attached in every session. See options. R_DOC_DIR: The location of the R ‘doc’ directory. Set by R. R_ENVIRON: Optional. The path to the site environment file: see Startup. Consulted at startup. R_GSCMD: Optional. The path to Ghostscript, used by dev2bitmap, bitmap and embedFonts. Consulted when those functions are invoked. Since it will be treated as if passed to system, spaces and shell metacharacters should be escaped. R_HISTFILE: Optional. The path of the history file: see Startup. Consulted at startup and when the history is saved. R_HISTSIZE: Optional. The maximum size of the history file, in lines. Exactly how this is used depends on the interface. On Unix-alikes, for the readline command-line interface it takes effect when the history is saved (by savehistory or at the end of a session). On Windows, for Rgui it controls the number of lines saved to the history file: the size of the history used in the session is controlled by the console customization: see Rconsole. R_HOME: The top-level directory of the R installation: see R.home. Set by R. R_INCLUDE_DIR: The location of the R ‘include’ directory. Set by R. R_LIBS: Optional. Used for initial setting of .libPaths. R_LIBS_SITE: Optional. Used for initial setting of .libPaths. R_LIBS_USER: Optional. Used for initial setting of .libPaths. R_PAPERSIZE: Optional. Used to set the default for options("papersize"), e.g. used by pdf and postscript. R_PCRE_JIT_STACK_MAXSIZE: Optional. Consulted when PCRE's JIT pattern compiler is first used. See grep. R_PDFVIEWER: The path to the default PDF viewer. Used by R CMD Rd2pdf. R_PLATFORM: The platform – a string of the form "cpu-vendor-os", see R.Version. R_PROFILE: Optional. The path to the site profile file: see Startup. Consulted at startup. R_RD4PDF: Options for pdflatex processing of Rd files. Used by R CMD Rd2pdf. R_SHARE_DIR: The location of the R ‘share’ directory. Set by R. R_TEXI2DVICMD: The path to texi2dvi. Defaults to the value of TEXI2DVI, and if that is unset to a value determined when R was built. Only on Unix-alikes: Consulted at startup to set the default for options("texi2dvi"), used by texi2dvi and texi2pdf in package tools. R_TIDYCMD: The path to HTML tidy. Used by R CMD check if _R_CHECK_RD_VALIDATE_RD2HTML_ is set to a true value (as it is by --as-cran. R_UNZIPCMD: The path to unzip. Sets the initial value for options("unzip") on a Unix-alike when namespace utils is loaded. R_ZIPCMD: The path to zip. Used by zip and by R CMD INSTALL --build on Windows. TMPDIR, TMP, TEMP: Consulted (in that order) when setting the temporary directory for the session: see tempdir. TMPDIR is also used by some of the utilities: see the help for build. TZ: Optional. The current time zone. See Sys.timezone for the system-specific formats. Consulted as needed. TZDIR: Optional. The top-level directory of the time-zone database. See Sys.timezone. no_proxy, http_proxy, ftp_proxy: (and more). Optional. Settings for download.file: see its help for further details. Unix-specific Some variables set on Unix-alikes, and not (in general) on Windows. DISPLAY: Optional: used by X11, Tk (in package tcltk), the data editor and various packages. EDITOR: The path to the default editor: sets the default for options("editor") when namespace utils is loaded. PAGER: The path to the pager with the default setting of options("pager"). The default value is chosen at configuration, usually as the path to less. R_PRINTCMD: Sets the default for options("printcmd"), which sets the default print command to be used by postscript. R_SUPPORT_OLD_TARS logical. Sets the default for the support_old_tars argument of untar. Should be set to TRUE if an old system tar command is used which does not support either xz compression or automagically detecting compression type. Windows-specific Some Windows-specific variables are GSC: Optional: the path to Ghostscript, used if R_GSCMD is not set. R_USER: The user's ‘home’ directory. Set by R. (HOME will be set to the same value if not already set.)

Report Capabilities of this Build of R Description Report on the optional features which have been compiled into this build of R. Usage capabilities(what = NULL, Xchk = any(nas %in% c("X11", "jpeg", "png", "tiff"))) Arguments what character vector or NULL, specifying required components. NULL implies that all are required. Xchk logical with a smart default, indicating if X11-related capabilities should be fully checked, notably on macOS. If set to false, may avoid a warning “No protocol specified” and e.g., the "X11" capability may be returned as NA. Value A named logical vector. Current components are jpeg is the jpeg function operational? png is the png function operational? tiff is the tiff function operational? tcltk is the tcltk package operational? Note that to make use of Tk you will almost always need to check that "X11" is also available. X11 are the X11 graphics device and the X11-based data editor available? This loads the X11 module if not already loaded, and checks that the default display can be contacted unless a X11 device has already been used. aqua is the quartz function operational? Only on some macOS builds, including CRAN binary distributions of R. Note that this is distinct from .Platform$GUI == "AQUA", which is true only when using the Mac R.app GUI console. http/ftp does the default method for url and download.file support ‘⁠http://⁠’ and ‘⁠ftp://⁠’ URLs? Always TRUE as from R 3.3.0. However, in recent versions the default method is "libcurl" which depends on an external library and it is conceivable that library might not support ‘⁠ftp://⁠’ in future. sockets are make.socket and related functions available? Always TRUE as from R 3.3.0. libxml is there support for integrating libxml with the R event loop? TRUE as from R 3.3.0, FALSE as from R 4.2.0. fifo are FIFO connections supported? cledit is command-line editing available in the current R session? This is false in non-interactive sessions. It will be true for the command-line interface if readline support has been compiled in and --no-readline was not used when R was invoked. (If --interactive was used, command-line editing will not actually be available.) iconv is internationalization conversion via iconv supported? Always true in current R. NLS is there Natural Language Support (for message translations)? Rprof is there support for Rprof() profiling? This is true if R was configured (before compilation) with default settings which include --enable-R-profiling. profmem is there support for memory profiling? See tracemem. cairo is there support for the svg, cairo_pdf and cairo_ps devices, and for type = "cairo" in the bmp, jpeg, png and tiff devices? Prior to R 4.1.0 this also indicated Cairo support in the X11 device, but it is now possible to build R with Cairo support for the bitmap devices without support for the X11 device (usually when that is not supported at all). ICU is ICU available for collation? See the help on Comparison and icuSetCollate: it is never used for a C locale. long.double does this build use a C long double type which is longer than double? Some platforms do not have such a type, and on others its use can be suppressed by the configure option --disable-long-double. Although not guaranteed, it is a reasonable assumption that if present long doubles will have at least as much range and accuracy as the ISO/IEC 60559 80-bit ‘extended precision’ format. Since R 4.0.0 .Machine gives information on the long-double type (if present). libcurl is libcurl available in this build? Used by function curlGetHeaders and optionally by download.file and url. As from R 3.3.0 always true for Unix-alikes, and as from R 4.2.0 true on Windows.

Complex vectors can be created with complex. The vector can be specified either by giving its length, its real and imaginary parts, or modulus and argument. (Giving just the length generates a vector of complex zeroes.)

All R platforms are required to work with values conforming to the IEC 60559 (also known as IEEE 754) standard. This basically works with a precision of 53 bits, and represents to that precision a range of absolute values from about 2 × 1 0 − 308 2×10 −308 to 2 × 1 0 308 2×10 308 . It also has special values NaN (many of them), plus and minus infinity and plus and minus zero (although R acts as if these are the same). There are also denormal(ized) (or subnormal) numbers with values below the range given above but represented to less precision. See .Machine for precise information on these limits. Note that ultimately how double precision numbers are handled is down to the CPU/FPU and compiler. In IEEE 754-2008/IEC60559:2011 this is called ‘binary64’ format.

It is a historical anomaly that R has two names for its floating-point vectors, double and numeric (and formerly had real). double is the name of the type. numeric is the name of the mode and also of the implicit class. As an S4 formal class, use "numeric". The potential confusion is that R has used mode "numeric" to mean ‘double or integer’, which conflicts with the S4 usage. Thus is.numeric tests the mode, not the class, but as.numeric (which is identical to as.double) coerces to the class.

Double-precision values All R platforms are required to work with values conforming to the IEC 60559 (also known as IEEE 754) standard. This basically works with a precision of 53 bits, and represents to that precision a range of absolute values from about 2 × 1 0 − 308 2×10 −308 to 2 × 1 0 308 2×10 308 . It also has special values NaN (many of them), plus and minus infinity and plus and minus zero (although R acts as if these are the same). There are also denormal(ized) (or subnormal) numbers with values below the range given above but represented to less precision. See .Machine for precise information on these limits. Note that ultimately how double precision numbers are handled is down to the CPU/FPU and compiler. In IEEE 754-2008/IEC60559:2011 this is called ‘binary64’ format.

An exception is an abnormal condition that occurs during the execution of a program. It interrupts the normal flow of instructions and must be handled properly to avoid program failure.

Checked Exceptions Checked exceptions are those that are detected at compile time. These are mainly used in languages like Java. The programmer is required to handle these exceptions, either using try-catch blocks or by declaring them with the throws keyword.

Unchecked Exceptions Unchecked exceptions occur at runtime and are not checked during compilation. These usually happen due to logical errors in the program.

Built-in Exceptions Built-in exceptions are predefined exceptions provided by programming languages. They cover common error scenarios and make error handling easier.

User-defined Exceptions User-defined exceptions are custom exceptions created by programmers to handle specific situations in their applications. This improves code clarity and allows better control over errors.

Exceptions and conditions provide the means for system and user code to signal, detect, and recover from errors that occur when a program is run.

Exceptions are raised by the standard syntactic forms and procedures under a variety of circumstances, e.g., when the wrong number of arguments is passed to a procedure, when the syntax of an expression passed to eval is incorrect, or when a file cannot be opened by one of the file open procedures. In these situations, the exception is raised with a standard condition type.

While a program may pass raise or raise-continuable any Scheme value, the best way to describe an exceptional situation is usually to create and pass a condition object. Where the Revised6 Report requires the implementation to raise exceptions, the value passed to the current exception handler is always a condition object of one or more of the standard condition types described in Section 11.3. User code may create a condition object that is an instance of one or more standard condition types or it may create an extended condition type and create a condition object of that type. Condition types are similar to record types but are more flexible in that a condition object may be an instance of two or more condition types, even if neither is a subtype of the other. When a condition is an instance of multiple types, it is referred to as a compound condition. Compound conditions are useful for communicating multiple pieces of information about an exception to the exception handler. A condition that is not a compound condition is referred to as a simple condition. In most cases, the distinction between the two is unimportant, and a simple condition is treated as if it were a compound condition with itself as its only simple condition.

Conditions of this type indicate situations of a serious nature that, if uncaught, generally result in termination of the program's execution. Conditions of this type typically occur as one of the more specific subtypes &error or &violation. This condition type might be defined as follows.

Conditions of this type indicate that the program has violated some requirement, usually due to a bug in the program.

This condition type indicates a specific violation in which the program has passed the wrong number or types of arguments to a procedure.

Conditions of this type indicate that an error has occurred with the program's interaction with its operating environment, such as the failure of an attempt to open a file. It is not used to describe situations in which an error in the program has been detected.

Warning conditions indicate situations that do not prevent the program from continuing its execution but, in some cases, might result in a more serious problem at some later point. For example, a compiler might use a condition of this type to indicate that it has processed a call to a standard procedure with the wrong number of arguments; this will not become a serious problem unless the call is actually evaluated at some later point.

Conditions of this type are usually included with a &warning condition or one of the &serious condition subtypes to provide a more specific description of the exceptional situation. The message argument to the constructor may be any Scheme value but is typically a string.

Conditions of this type are usually included with a &message condition to provide information about Scheme values that may have caused or been materially involved in the exceptional situation. For example, if a procedure receives the wrong type of argument, it may raise an exception with a compound condition consisting of an assertion condition, a who condition naming the procedure, a message condition stating that the wrong type of argument was received, and an irritants condition listing the argument. The irritants argument to the constructor should be a list.

Conditions of this type are often included with a &message condition to identify the syntactic form or procedure that detected the error. The who argument to the constructor should be a symbol or string.

Conditions of this type indicate that a non-continuable violation has occurred. raise raises an exception with this type if the current exception handler returns.

An implementation-restriction condition indicates that the program has attempted to exceed some limitation in the implementation, such as when the value of a fixnum addition operation would result in a number that exceeds the implementation's fixnum range. It does not normally indicate a deficiency in the implementation but rather a mismatch between what the program is attempting to do and what the implementation can support. In many cases, implementation restrictions are dictated by the underlying hardware.

Conditions of this type indicate that a lexical error has occurred in the parsing of a Scheme program or datum, such as mismatched parentheses or an invalid character appearing within a numeric constant.

Conditions of this type indicate that a syntax error has occurred in the parsing of a Scheme program. In most implementations, syntax errors are detected by the macro expander. Each of the form and subform arguments to make-syntax-violation should be a syntax object (Section 8.3) or datum, the former indicating the containing form and the latter indicating the specific subform. For example, if a duplicate formal parameter is found in a lambda expression, form might be the lambda expression and subform might be the duplicated parameter. If there is no need to identify a subform, subform should be #f.

An undefined condition indicates an attempt to reference an unbound variable.

The next several condition types describe conditions that occur when input or output operations fail in some manner.

A condition of type &i/o indicates that an input/output error of some sort has occurred. Conditions of this type typically occur as one of the more specific subtypes described below.

This condition type indicates that an error has occurred while reading from a port.

This condition type indicates that an error has occurred while writing to a po

This condition indicates that the implementation has no representation for infinity. T

This condition indicates that the implementation has no representation for NaN

We’re bringing OpenTelemetry to R. As a Posit-wide initiative across our open source packages, we’ve instrumented some of the most widely-used R packages for production workloads – Shiny, plumber2, mirai, httr2, ellmer, knitr, testthat and DBI.

What is OpenTelemetry?# OpenTelemetry (OTel) is a vendor-neutral, open source observability framework backed by the Cloud Native Computing Foundation. It has broad industry support across languages and platforms, and is already the standard in the Python, Java, JavaScript, and Go ecosystems. Now it’s available for R. OpenTelemetry defines a standard for collecting telemetry data: Traces follow an operation as it moves through your system, showing exactly which functions ran, in what order, and how long each took. Metrics capture numerical measurements over time – things like request counts, response latencies, or memory usage. Logs record detailed events as they happen, providing context when you need to investigate a specific moment. The instrumented packages described in this post all use the otel package under the hood, and focus on traces, which provide the most immediate value for understanding production behavior. You can also use otel directly to add your own metrics and logs to your application code.

Why observability matters for R in production# When you’re developing interactively in RStudio or Positron, debugging is straightforward – you can step through code, inspect objects, and add print statements. But when your R code runs in production – a Shiny app serving hundreds of users, a plumber2 API handling thousands of requests, a batch pipeline running across a cluster – the picture changes. The core concept in OpenTelemetry is a trace: the full path of a request through your system. Each trace is made up of spans – individual units of work with a name and a duration.

This structure gives you four things that are hard to get any other way: Performance: Which part of a request is slow? Span durations pinpoint where time is spent – and nesting reveals unnecessary overhead. Errors: In development and testing, you know where errors are – you wrote the test, you control the inputs. In production, errors surface far from their root cause, across process boundaries and async operations, triggered by conditions you never anticipated. Traces show you the full chain of real operations that led to each failure, in the context where it actually happened. Centralized view: When your application extends across multiple R processes or machines – a Shiny app with mirai workers, or a plumber2 API behind a load balancer – traces are aggregated into a single view across all of them. Real-time monitoring: OTel is designed to be left on in production, not just enabled during testing or staging. With low overhead, it runs continuously – so you see what’s happening as it happens, and dashboards and alerts catch problems before users report them.

Instrumented packages# We’ve worked across teams to add OpenTelemetry instrumentation to the R packages where it matters most: Package Version What it traces Shiny ≥ 1.12.0 Session lifecycle, reactive updates, reactive expressions, background tasks plumber2 ≥ 0.2.0 API request handling, routing, endpoint execution mirai ≥ 2.5.0 Task dispatch, daemon execution, results httr2 ≥ 1.2.2 HTTP requests and responses ellmer ≥ 0.4.1 LLM API calls, tool execution, token usage knitr ≥ 1.51 Document rendering, chunk evaluation testthat ≥ 3.3.2 Test execution DBI ≥ 1.3.0 Database queries and connections

To make this concrete, let’s look at a Shiny chat app built with shinychat and ellmer that fetches weather forecasts. It uses mirai for async execution and httr2 for weather API requests.