Error

Errors and exceptions in angle are tightly linked with the concept of optionally in variables:

The function parse string as int? either returns an int or a typed error "missing int" !int with associated (?todo) type format error or number to large etc

The result can be handled positively:
if result { print "we have a number %d" % result }
if no result { print "parse did not return a number" }
if result failed { print "we have an error %e" % result } or
if result failed { print "we have an error %s" % result.error }
on error { print "we have an error %e" % error }

Just like in swift optionals can be unwrapped with tailing ! which throws if the variables value is missing or erroneous.

Errors vs exceptions / signals

Errors are non throwing value types, exceptions are ... special: they will propagate through the call stack unless they are explicitly caught, unlike in Java and similar languages, the try keyword is not necessary to catch errors, and a catch statement outside a block will catch all exceptions for its declared method:

fun do_dirty_stuff(){
 eat ()
 drink ()
 catch (no food){}
 catch (drunkenness){}
 on error{}
}

Exceptions can be converted (back) into errors with the try keyword: int? i=try parse (string) needs no further catch block

Exceptions are special signals Because errors have their own value mechanism, using signals for control flow is encouraged:

fun check the surroundings {
  if man nearby: 
    raise stop the machine!
}

fun main {
 go check the surroundings // asynchronous
 on stop the machine{
  cancel everything
  panic
  exit
}
}

When do functions throw, when do they return optionals?

To avoid function coloring, we may introduce the following convention: int i= parse (string) is legal but marks the containing function as potentially throwing int? i= fun (string) catches any potential integer errors, but not exceptions
functions explicitly marked as throwing need not return optional values: parse string as int may fail is identical to parse string as int? Only when there are multiple return values will these notations differ.

Note that no result is true both for missing and erroneous objects, which might be sufficient for most control flow, otherwise one can distinguish with result == 0 == result null result missing result empty and result failed