Error Handling Across Programming Languages

Errors and allocated resources

The biggest pitfall (and most important solutioning) around errors is resource allocation and deallocation. The most commonly allocated resource developers talk about is memory. However, memory allocation is not the only resource that programs need to manage. It is important to note that "memory safety" does not guarantee "program safety". A program may be "memory safe", but may leak other critical resources of a computer or may exhibit other unsafe behavior. Other resources that programs need to manage include (but are not limited to):

• Network sockets
• File handles
• Database connections
• GPU resources (e.g. logical devices, GPU memory, pipelines, etc.)
• Results/memory from FFI calls (or native code wrappers or WASM)
• Globally cached data
• Observable subscriptions

class ExampleFile {
  public void write(String contents) throws IOException {
    var file = new FileWriter("example.txt");
    try {
      file.write("hello world!");
    }
    finally {
      file.close();
    }
  }
}

using (StreamReader exampleFile = File.OpenText("file.txt"))
{
  string line;
  while ((line = reader.ReadLine()) is not null)
  {
    Console.Write(line);
  }
}

RAII

The RAII (Resource Acquisition Is Initialization) pattern is mostly specific to C++ and Rust. In this pattern, the lifetime of an allocated resource (memory, file handle, socket, etc.) is bound to the lifetime of an object. Once that object's lifetime ends, the corresponding resource is automatically deallocated. This allows for powerful constructs which allow for automatic resource management. For instance, below is code which does both automatic memory management and automatic file handle management:

#include <memory>
#include <filesystem>
#include <cstdio>
#include <vector>
#include <optional>
#include <iostream>

class ReadFileHandle {
  FILE* cFileHandle;
  public:
  ReadFileHandle(const std::filesystem::path& filePath)
  : cFileHandle(std::fopen(filePath.c_str(), "r")) {}
  
  ~ReadFileHandle() {
    if (is_valid()) {
      // Close our file handle automatically
      std::fclose(cFileHandle);
    }
  }
  
  [[nodiscard]] auto is_valid() const -> bool { return cFileHandle != nullptr; }
  
  [[nodiscard]] auto read_file() const -> std::optional<std::string> {
    if (!is_valid()) {
      return std::nullopt;
    }
    
    // Read the entire file into memory
    std::fseek(cFileHandle, 0, SEEK_END);
    size_t size = ftell(cFileHandle);
    auto buffer = std::string(size, '\0');
    std::rewind(cFileHandle);
    std::fread(buffer.data(), sizeof(char), size, cFileHandle);
    return buffer;
  }
};

int main() {
  // Allocate memory
  auto fileHandle = std::make_unique<ReadFileHandle>(
  std::filesystem::current_path() / "example.txt"
  );
  
  // Print the contents of the file (or an error message)
  std::cout << fileHandle->read_file().value_or("<could not open file>") << "\n";
  
  // No need to manually deallocate memory, that's done automatically
  // Also, no need to close the file handle, that's also done automatically
  throw std::runtime_error("some error happened");
}

The advantage is that since this is tied to object lifetime cleanup, we can better integrate it with coroutines and suspending functions. Essentially, when a suspended callstack is cleaned up, it will call the destructors for any objects tied to that callstack. There are some disadvantages though. One notable one is that RAII heavily relies on the callstack. If there is a deeply nested data structure which relies on recursive RAII (e.g. tree, graph, linked list), then destructuring can exceed callstack size and result in an exception.

defer and scope exit

The defer pattern defers some block of code to run once the scope is left. This is useful for both deallocating resources normally, and deallocating resources during an error. Usually, defer is at scope exit, though some languages (e.g. Go) are at function exit.

For instance, here's a Zig program using scoped defer:

const std = @import("std");

pub fn main() void {
  {
    defer std.debug.print("Print 1\n", .{});
  }
  
  std.debug.print("Print 2\n", .{});
  
  {
    defer std.debug.print("Print 3\n", .{});
  }
}

// Output:
//  Print 1
//  Print 2
//  Print 3

Here's a Go program using function defer:

package main

import ("fmt")

func main() {
  {
    defer fmt.Println("Print 1")
  }
  
  fmt.Println("Print 2")
  
  {
    defer fmt.Println("Print 3")
  }
}

// Output:
//  Print 2
//  Print 3
//  Print 1

The difference in scope defer vs function defer can lead to some interesting gotchas when transitioning between the two systems. However, for the purposes of resource deallocation, either methodology works, so we'll treat them as equally capable for the rest of the article.

The defer statement will usually appear immediately after a resource is allocated. This will guarantee that the resource is properly deallocated, even when an error occurs. Below is an example:

func DoSomethingWithFile(fileName string) {
  src, err := os.Open(fileName)
  if err != nil {
    return
  }
  // Guarantees we close our file handle
  defer src.Close()
  
  // Do what we need to with the file here
}

Some of the languages with built-in defer (or equivalent) support include:

• Zig[1] - Uses scoped defer (and also has error-specific defers[2])
• Go[3] - Uses function defer
• D[4] - Uses scoped guard which is similar to scoped defer

Inability to know when to handle errors

The first issue with the try/catch arises when error throwing starts happening deep in the callstack, or when we call code in a library (including the language's standard library) where it's not obvious when we throw. For instance, consider the following code:

const importedCode = require('some-library').init()

importedCode.runAction();

Which lines require us to use a try/catch? Which lines don't? We could try to go through the documentation, but not every library documents what is thrown. If this was a first-party library (e.g. an internal company library), the chances that it's properly documented drop quickly.

There have been attempts to resolve this issue. For example, Java requires most uncaught errors to be documented as part of the method signature. For example, consider the following code:

public class Main {
  // we catch our exceptions, so don't add it to the signature
  public static void catcher() {
    try {
      thrower();
    }
    catch (Exception e) {
      System.out.println("Caught exception!");
    }
  }
  
  // We throw, so it has to be part of the signature
  public static void thrower() throws Exception {
    throw new Exception("Something happened");
  }
  
  // We call a method that throws, but don't handle it ourselvs
  // we must declare that in our signature
  public static void main(String[] args) throws Exception {
    catcher();
    thrower();
  }
}

Requiring code to document when it throws seems like the solution. Whenever we declare an error a method must make that explicit and everything's good, right?Well, not quite. One common trend I've noticed from these systems is they usually include ways to "hide" errors. For instance, we can write the following code.

public class Main {
  public static void thrower() {
    throw new RuntimeException("Something happened");
  }
  
  public static void main(String[] args) {
    // will end the program since the exception is not caught
    thrower();
  }
}

One of the reasons for this bypass system to exist is so that develoeprs can extend "non-throwing" interfaces with code which might throw. For instance, consider the following code:

interface NumberGenerator {
  // Since we don't have a "throws" as part of the signature,
  //  no implementation may have a "throws" as part of their
  //  method signature either
  int number();
}

class StaticNumberGenerator implements NumberGenerator {
  // No exceptions, no problem
  @Override
  public int number() { return 4; }
}

class RequestNumberGenerator implements NumberGenerator {
  // We can throw, but we can't have those exceptions
  //  as part of our signature since our interface
  //  doesn't have it as part of it's signature
  @Override
  public int number()  {
    HttpRequest request = HttpRequest.newBuilder()
    .uri(URI.create("https://example.com/"))
    .timeout(Duration.ofMinutes(2))
    .header("Content-Type", "application/json")
    .GET()
    .build();
    
    var client = HttpClient.newBuilder()
    .version(HttpClient.Version.HTTP_1_1)
    .followRedirects(HttpClient.Redirect.NORMAL)
    .connectTimeout(Duration.ofSeconds(20))
    .authenticator(Authenticator.getDefault())
    .build();
    try {
      // this line can throw different exceptions,
      // but since we're imp
      HttpResponse<String> response = client.send(
      request,
      HttpResponse.BodyHandlers.ofString()
      );
      return response.body().length();
    }
    catch (Exception e) {
      // The "workaround" is to convert all of our exceptions to
      //   a RuntimeException so that we can throw
      throw new RuntimeException("Could not fetch resource", e);
    }
  }
}

In the above code, we have an interface which doesn't let its member functions throw errors. This is pretty common, especially when the interface is defined in one library but the implementation is defined in another (e.g. a library allows developers to provide a custom implementation of an interface).

However, since Java chose to have the errors as part of the method signature, we can't "throw" an error in the implementation. If we did, that would be a violation of the interface specification! But we may not always be able to correct the error in our implementation. For instance, what if in some cases we wanted to try the RequestNumberGenerator implementation first, but then fallback to the StaticNumberGenerator implementation? If the RequestNumberGenerator wasn't allowed to tell us if it failed, we wouldn't be able to implement our fallback logic.

The workaround is to "hide" the errors that are thrown by using RuntimeException. This allows us to throw whenever we need to without changing the interface. But, now we're back to square one. We weren't able to identify when we threw an error message which meant we didn't know when we needed a try catch, so we just required everything to annotate when it throws an error, but then we ran into an issue with interfaces, so we decided to allow code to hide when it throws errors, which means we don't actually know when code throws an error.

In fact, we're in a worse place because now we have a system which lets people think they know when an error will be thrown, but that system is incorrect and so now we can have code which appears to not throw but in reality it does throw.

Other systems with annotating thrown errors run into similar issues. For instance, PHP lets users annotate the errors which are thrown. However, interfaces run into the same issue as Java interfaces, so we won't always know when a method truly throws or doesn't throw.

The inability to reliably know when to add a try/catch is the single largest downfall of the model. It makes it impossible for developers to reliably know if they've handled errors properly, and all the attempts to remedy the issue have resulted in partial solutions which don't reliably work.

Control Flow

The try/catch pattern does introduce more complicated control flow. Any statement could theoretically result in an error, and that error will change the flow of the program. Extra care needs to be taken to ensure resources are properly deallocated. Additionally, debugging and understanding code can get more complicated since the control flow is not linear (i.e. it does not strictly follow how the code is read since it may jump higher in the call stack at any point).

Error flag and global error

This model is most common in C code, though it will also appear in other languages (I've seen it in PHP). The basic idea is that code will return whether it passed, and it will set a global variable with details about the error.

Generally, this code is meant to only run in a single threaded context (such as during program initialization). Running code like this in a multithreaded context can cause race conditions since multiple threads could be trying to set the global error variable at teh same time. Below is an example of this pattern using the SDL[7] library:

int main (int argc, char **argv)
{
  // Initialize SDL. If we get an error code, print the error
  if (SDL_Init(SDL_INIT_VIDEO) != 0) {
    fprintf(stderr, "SDL failed to initialise: %s\n", SDL_GetError());
    return 1;
  }
  
  // code goes here
  
  // Clean up SDL
  SDL_Quit(); 
}

This pattern does not hold up in a multithreaded environment without heavy use of locks or thread-locals, so it shouldn't be used regularly.

Another disadvantage is that this error pattern usually cannot enforce that errors are handled or checked for (though some languages have added features to require that a return value is used, such as C++'s [[nodiscard]][8]). This means that an error which should be addressed can go ignored which can cause further issues and bugs in the program.

The reliance on a global variable for setting error information can cause other issues when developers either don't understand the pattern or they don't fully adhere to the pattern. Sometimes developers will ignore the return flag and check the global variable, or they won't return a flag and only set the global on an error. In these cases, it's quite possible to get incorrect error detection logic - especially if an error was ignored earlier in the code. Below is some PHP code which shows this behavior (this is based on real code in a real production environment):

<?php
$lastError = null;

function willFail() {
  global $lastError;
  // Set our error message
  $lastError = 'Called willFail';
  return false;
}

function willPass() {
  return true; // indicate success
}

willFail();

// We should check for an error, but we don't

// ... lots of other code here

willPass();

// Yes, some devs would check the global
//  and not the returned flag
if (!empty($lastError)) { 
  echo "willPass failed! Error: {$lastError} \n";
}
else {
  echo "willPass succeeded!\n";
}

This pattern has outlived its usefulness. We are now in a multithreaded age, so having a single-threaded pattern heavily limits what we can do. Additionally, I've had to work with enough code where developers would ignore critical errors, which then caused code which was trying to handle errors to handle an error incorrectly (similar to the above example). A lot of old code still uses this pattern, so it's good to know what the pattern is and how to work with it when needed. However, it shouldn't be used in new code.