Closed dumblob closed 1 year ago
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.
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.
Could error handling be made more visible?
Currently
try
andcatch
are not required each time a call is being done to a function potentially returning error (actuallynone
- 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 returningnone
. This is what e.g. V does and it makes it a much more secure language.Thoughts? Any changes planned in this regard?