I agree but even than I cant decide in LevelManager which Errors will be handled in LevelManager itself and which one will be passed to the UIScreen and will be handled there
a simple forcecatch annotation or something like that would be so nice just to tell the compiler here is an error this breaks my complete Architecture of Error Handling, in Java it was so nice you could always decide on which hierarchy you want to fix your Errors and push some of them into the higher hierarchy when needed
You can, but it requires yet another sealed class. I agree it is a bit more tiresome.
But even then I have to use When with expression all the time to cover up all possibilities I think Kotlin need a nicer way for Error Handling or at least some way to force the Method Caller to handle with possible Errors because dealing with Errors is really necessary in every Language
The union return type (with the sealed classes) approach to error handling is a functional approach. You don’t have
when statements all over the place, instead you use a map/apply function that will only be invoked by the success path. Only when you want the end result do you need to handle the option of an error. But in this case your errors are predictable and you don’t have to handle partially changed state etc. that you need for exception safety. You also don’t have to handle “foreign” exception types (or exception wrapping) which is one of the major issues with checked exceptions.
That is not the general finding of those that have studied the matter. The oft quoted counter to that is:
Examination of small programs leads to the conclusion that requiring exception specifications could both enhance developer productivity and enhance code quality, but experience with large software projects suggests a different result – decreased productivity and little or no increase in code quality.
Ask yourself, why other languages have not adopted checked exceptions.