Rescue in SketchUp

In Ruby, exceptions are the standard mechanism for handling errors. When something goes wrong, code can raise an exception, and a surrounding rescue block can catch it and respond. This is analogous to throw/catch in languages like Java or C#. At its simplest, it looks like this:

begin
  # Code that might fail
rescue => e
  # Handle the error
end

A common misconception among SketchUp extension developers is that you need to rescue exceptions to prevent crashes. In many other Ruby environments this is true -- an unhandled exception can bring down a server or terminate a script. However, SketchUp itself already rescues uncaught exceptions and displays them in the Ruby console. This means your extension won't crash SketchUp if an exception goes unhandled. SketchUp has you covered.

The Silent Rescue Anti-Pattern

A somewhat common anti-pattern is to rescue an exception without doing anything with it. This silently swallows the error, hiding problems and making them much harder to diagnose.

# Bad
begin
  # Code here...
rescue
  # Not doing anything with the exception
end

When an error occurs inside this block, nothing happens. No message is shown, no error is logged, and the developer gets no indication that something went wrong. Bugs that would otherwise be obvious become invisible.

Misleading Error Messages

Even worse is to rescue and show a potentially misleading error message. If the user cannot sign in due to an SSL error, they should not be told they mistyped their login credentials.

# Worse
begin
  # Code here...
rescue
  # Misleading error message
  UI.messagebox("Incorrect username or password")
end

Because this catches all exceptions indiscriminately, any failure -- a network timeout, an SSL certificate error, an unexpected nil -- gets reported as an incorrect password. This sends the user on a wild goose chase and makes the real issue nearly impossible to track down.

Just Don't Rescue

To allow users and yourself to detect malfunctioning and fix it, you can simply skip rescuing altogether. SketchUp already catches unhandled exceptions and prints the error message and backtrace to the Ruby console. This gives both the developer and technically inclined users the information they need to understand and report the problem.

# Good
# Code here... - no rescue needed

Optional: User-Friendly Error Reporting

If you want to go the extra mile, you can rescue exceptions and display the actual error message to the user. Either use UI.messagebox for a simple dialog, or use UI::HtmlDialog for a richer presentation. The latter allows additional styling and could include contact information so the user can reach you, the developer, directly.

# Also good
begin
  # Code here...
rescue => e
  UI.messagebox("EXTENSION-NAME ran into a problem\n\n#{e.message}")
end

When Rescue Is Appropriate

There are situations where rescuing is the right thing to do. The key distinction is whether the exception represents a genuine, expected failure mode that your code should handle gracefully.

A good example is String#to_l, a SketchUp method that converts a string to a Length. It raises an ArgumentError when the input is not a valid length, which is expected to happen when dealing with user input. In this case, rescuing the specific exception and giving the user a clear message is the correct approach.

input = UI.inputbox(["Length"], [""])
begin
  length = input[0].to_l
rescue ArgumentError
  UI.messagebox("Invalid Length")
else
  UI.messagebox("You entered #{length}")
end

Note that this example rescues only ArgumentError, not all exceptions, and only around the relevant line of code. It handles one specific, anticipated failure and lets any unexpected errors propagate normally to SketchUp's own error handling.

Summary

If you are unsure whether to rescue, don't. Let SketchUp handle the exception. You'll get a clear error message in the Ruby console, which is far more useful than a silent failure or a misleading dialog box.