Ruby Exception Handling

Ruby Exception Handling: SystemCallError

Moving along through our Ruby Exception Handling series, today we’ll be checking out the SystemCallError and it’s closely associated Errno subclasses. SystemCallErrors are raised during any low-level, platform-dependent exceptions like invalid IO calls and the like.

In this article we’ll explore the SystemCallError in more detail, including where it resides in the Ruby Exception class hierarchy. We’ll also take a look at a few simple code examples to illustrate how SystemCallErrors and their corresponding Errnos show up in the first place, so let’s get to it!

The Technical Rundown

  • All Ruby exceptions are descendants of the Exception class, or a subclass therein.
  • StandardError is a direct descendant of the Exception class, and is also a superclass with many descendants of its own.
  • SystemCallError is the direct descendant of StandardError.
  • Errno is a module with dozens of subclasses contained within it, all of which are direct descendants of SystemCallError.

When Should You Use It?

SystemCallError is somewhat unique in the realm of Ruby exception classes because it isn’t raised directly. Instead, SystemCallError is the base class for dozens of Errno module subclasses. To view the list of possible Errno classes simply output Errno.constants through an interactive Ruby console (irb) or similar tool. According to the official documentation, the list of possible Errno module classes is dependant on the operating system that Ruby is running on, but as it happens, the list is identical in Ruby 2.3 on both Windows 7 and Ubuntu 16.04 (Unix):

Unix Errno constants:

Windows Errno constants:

Since all low-level errors produce an appropriate Errno subclass from the constant list above, there are clearly many possible ways to raise SystemCallErrors in the first place. We don’t have time to cover them all here so we’ll just give a brief example and see how we can best rescue the specific errors we’re after.

First, it’s important to remember that since SystemCallError is the base class of which all Errno classes inherit, we can actually capture all possible Errno errors by rescuing SystemCallError. For example, here we are trying to open a Fileobject with an invalid file path provided as the argument. This raises a Errno::ENOENT error, but since all Errno subclasses inherit from SystemCallError, we can rescue them all using that base class:

As expected, our explicit rescue of SystemCallError works just fine and outputs the EXPLICIT result we expected:

While we can rescue the Errno::ENOENT class directly, it’s important to remember that Ruby will systematically check each rescue clause in order until it finds one that matches the error that was raised. This means that even if we explicitly rescueErrno::ENOENT, if such a rescue comes after SystemCallError, the base class of SystemCallError still qualifies as a match and occurs first:

To illustrate this ordering we’ve added some simple output messages inside each rescue block above to indicate which particular rescue statement was responsible for catching our error. This helps us show that, sure enough, that first rescuecatches our Errno::ENOENT exception, even though we explicitly rescue that class later on in the same begin-rescue-endblock:

This shows the importance of ordering your rescue classes properly, usually beginning with the lowest-level classes and working up toward the basest classes. Thus, for our example, starting with Errno:ENOENT that ensures that the Errno::ENOENTerrorr is caught by that statement and processed in that block. Any other Errno classes can then be caught by the second SystemCallError rescue, while all other errors are caught by the plain rescue block at the last:

As expected, this shows an EXPLICIT error output from rescue Errno:ENOENT:

It may also be useful to combine multiple classes into a single rescue statement. For example, we could combine Errno::ENOENT with SystemCallError in a single rescue statement like so:

The produced output:

To get the most out of your own applications and to fully manage any and all Ruby Exceptions, check out the Airbrake Ruby exception handling tool, offering real-time alerts and instantaneous insight into what went wrong with your Ruby code, including integrated support for a variety of popular Ruby gems and frameworks.