Imprisoning the Panic

func divide(a, b float64) (float64, error) {
	if b == 0 {
		return 0, errors.New("division by zero")
	}
	return a / b, nil
}

result, err := divide(num1, num2)

if err != nil {
	fmt.Println("Oh no, it's an error:", err)
} else {
	fmt.Printf("Result: %f", result)
}

So, there is no unwrapping, and result inspection should not cause a panic. But there are other ways to cause a panic in Go, like trying to read a nil value or directly causing a panic with the panic function. Luckily, there is a way to catch a panic and process it gracefully:

func main() {
	defer func() {
        if r := recover(); r != nil {
            fmt.Println("Recovered. Error:\n", r)
        }
    }()
    mayPanic()
    fmt.Println("After mayPanic()")
}

There is no way to prevent a process exit with os.Exit(code) call, so we can’t be fully protected from the foreign code misbehavior.

Python

Python uses exceptions as the main error-handling mechanism. There are built-in exceptions, and a developer can define their own exceptions by inheriting from the Exception class:

def divide(a, b):
  return a / b

try:
  result = divide(10, 0)
except ZeroDivisionError as e: # or "Exception as e" to catch all exceptions
  print("Error:", e)

To exit a program, one can use sys.exit(code) function, which actually raises a SystemExit exception. And that means we can catch it and prevent the abrupt termination of a program. There is also an os._exit(code) function that terminates the process immediately without any cleanup and cannot be caught, so there is no way to fully protect from that situation, but it’s also a pretty exotic and extreme case.

Java

Now, Java also uses exceptions as the main error-handling mechanism, which is very similar to Python. For a forceful exit, there is a System.exit(code) or Runtime.getRuntime().exit(code) methods that terminate the process, but can be caught by a shutdown hook:

public class ExitProtectionDemo {
  public static void main(String[] args) {
    SecurityManager original = System.getSecurityManager();
    try {
      // Install protective security manager
      System.setSecurityManager(new SecurityManager() {
        @Override
        public void checkExit(int status) {
          throw new SecurityException("Exit blocked: " + status);
        }
        
        @Override
        public void checkPermission(java.security.Permission perm) {
          // Allow everything else
        }
      });
      
      // This would normally terminate the program
      System.out.println("About to call System.exit()...");
      System.exit(42);
    } catch (SecurityException e) {
      System.out.println("Caught: " + e.getMessage());
      System.out.println("Program survived!");
    } finally {
      // Restore original security manager
      System.setSecurityManager(original);
    }
  }
}

This approach is considered deprecated in newer versions, and it also doesn’t catch Runtime.halt(code) calls that immediately terminate the JVM.

Javascript

Once again, JavaScript uses exceptions for error handling, with the difference that it’s not possible to only catch certain exceptions, so developers should filter out and process inside the catch block:

function referenceUnknownVariable() {
  return unknownVar;
}

try {
  referenceUnknownVariable();
} catch (ex) {
  if (ex instanceof ReferenceError) {
    console.log("Caught a ReferenceError:", ex.message);
  } else {
    console.error("Unexpected error:", ex);
  }
}

It doesn’t make much sense to use division by zero as an example, since it’s a totally legit operation in JavaScript, and the result is Infinity! That’s definitely an interesting way to avoid abrupt termination. For a forceful exit, there is a process.exit(code) method in Node.js, which immediately terminates the process and cannot be caught. But JavaScript wouldn’t be a meme if there wasn’t some weird way to work around that:

const originalExit = process.exit;

class ExitException extends Error {
  constructor(code) {
    super(`Exit blocked: ${code}`);
    this.code = code;
  }
}

process.exit = (code) => {
	throw new ExitException(code);
};

...

originalExit.call(process, code); // when you really want to exit

C++

I won’t go into details, C++ has exceptions similar to Java and Python as a main historical mechanism for error handling, but it also has a structure similar to Rust’s Result type in the form of std::expected (since C++23). There are also forceful termination methods, some of which can be caught via global handlers, and some cannot.

Summary

From the catch and recovery standpoint, JavaScript and Go seem to be the most permissive languages, with Go’s recovery function and JavaScript’s ability to monkey-patch whatever you want. I don’t see obvious gaps in other languages, though, so it all comes down to picking the right robust tools for the job. I would suggest scanning 3rd party libraries for any direct process termination calls if this is a critical requirement for your project.

After thorough thinking, I still believe that careful architectural design is the best long-term failure tolerance strategy. If your service has a non-critical dependency that relies on external setup, make sure that failure of that dependency doesn’t block or crash your main service. Another strategy is to partition your service into multiple clusters and do a gradual rollout of new versions to minimize the blast radius. After all, the language is just a tool, and it’s up to you not to smack your thumb with it.

About Author

Eduard Dykman is a full-stack engineer at Archetype AI. With a Master's degree in applied mathematics and cybernetics, and vast experience in startups and big tech like Yandex and Databricks, Eduard is focused on finding the balance between product delivery and technical robustness and maturity.