Exception handling: 'catch' without explicit 'try'

Question

I'm working on a new general-purpose programming language. Exception handling is supposed to be like in Rust, but simpler. I'm specially interested in feedback for exception handling (throw, catch).

Questions:

• The catch catches all exceptions that were thrown within the scope. I argue there is no need for try, because try would requires (unnecessary, in my view) indentation, and messes up diffs. I wonder if other programming languages have this feature? I didn't find any. Is there a problem with this idea?

• I think one exception type is sufficient. It has the fields code (int), message (string), and optional data (payload - byte array). Do you see any obvious problem with this?

Exceptions

throw throws an exception. catch is needed, or the method needs throws. In the following example, the scope of the catch is the while loop.

fun factorial(x int) int throws
    if x > 20
        throw exception('Value too large')
    if x <= 1
        return 1
    f := factorial(x - 1)
  return x * f

fun main()
    i := 0
    while i <= 30
        println('Factorial of ' i ' is ' factorial(i))
        catch e
            println('Factorial of ' i ' resulted in ' e.message)
        i += 1

Answer 1

In Ruby, an exception handling block looks like this:

begin
  # something which might raise an exception
rescue SomeExceptionClass => some_variable
  # code that deals with some exception
rescue SomeOtherException => some_other_variable
  # code that deals with some other exception
rescue YetAnotherException
  # code that deals with yet another exception and does not capture it
rescue
  # code that deals with any sub-exception of `StandardError`
else
  # code that runs only if *no* exception was raised
ensure
  # ensure that this code always runs, no matter what
  # does not change the final value of the block
end

Most of the clauses are optional.

There are some language constructs which form implicit exception blocks, namely method definition bodies and block bodies. So, instead of

def foo
  begin
    # something which might raise an exception
  rescue SomeExceptionClass => some_variable
    # code that deals with some exception
  rescue SomeOtherException => some_other_variable
    # code that deals with some other exception
  rescue YetAnotherException
    # code that deals with yet another exception and does not capture it
  rescue
    # code that deals with any sub-exception of `StandardError`
  else
    # code that runs only if *no* exception was raised
  ensure
    # ensure that this code always runs, no matter what
    # does not change the final value of the block
  end
end

you can also write

def foo
  # something which might raise an exception
rescue SomeExceptionClass => some_variable
  # code that deals with some exception
rescue SomeOtherException => some_other_variable
  # code that deals with some other exception
rescue YetAnotherException
  # code that deals with yet another exception and does not capture it
rescue
  # code that deals with any sub-exception of `StandardError`
else
  # code that runs only if *no* exception was raised
ensure
  # ensure that this code always runs, no matter what
  # does not change the final value of the block
end

And the same for blocks.

Answer 2

You are losing a lot.

For example, in Swift a non-throwing function isnt allowed by the compiler to call a throwing function outside a try block - which means that I, as the developer, know definitely that no code outside the “catch” can throw exceptions, guaranteed by the compiler. And if you call any code that could throw exceptions after the last catch ghen you must report an error. Now what if the catch statement is inside an if?

Functions don’t catch exceptions all over the place. Exceptions are exceptional. You have functions that do nothing that can throw exceptions, and then enter one area where exceptions can happen. I want to handle exceptions in that area - and be sure there are no exceptions elsewhere. So my “catch” code knows which exceptions should arrive and which shouldn’t.