Error handling, its (in)visibility and the curse of 3-state logic

[dumblob]

Could error handling be made more visible?

Currently try and catch are not required each time a call is being done to a function potentially returning error (actually none - but read below). That leads to poor visibility - when reading the code - into whether errors can be produced by the call or not.

Also, supporting none as non-unusal value is a book example of the billion dollar mistake. Three-state logic is notoriously difficult to handle and our brains are simply not made for that.

Thus none shall be fully checked in compile time by making it visible by requiring the programmer to explicitly handle it at the caller place of a function potentially returning none. This is what e.g. V does and it makes it a much more secure language.

Thoughts? Any changes planned in this regard?

[fubark]

The current plan is that you would have to handle the error if it's passed to a typed destination, and you'd also need to have a value where it's type is an error union. I would like to see Cyber example code that demonstrates what you have a problem with.

[fubark]

Error handling has changed to a try/catch model for expected errors and they will bubble up by default until you have caught them. The issue with just using error values is that it was easy for the user to not handle them since not everything in Cyber is fully typed.

As for making it more visible, declaring typed functions like func foo() number: would require you to handle all errors inside the body or you would have to do func foo() throws number.

Using an untyped function func foo(): is equivalent to declaring it as func foo() throws any

As for none I don't think we can require the user to handle them since you can call into untyped lambdas which don't have a typed signature at compile time.