In my opinion, yeah it’s pretty unnatural. Well, at the worst maybe just messy and ugly. Sure, those aren’t deal breakers, I’m not saying Kotlin is a bad language because of this, but for me it’s a major pain point. Everywhere else Kotlin is clean and accomplishes it’s goals with simplicity, but here it falls flat on it’s face. Even with additional methods you still have the issue that to get any kind of exception handling built in you always have to nest it inside another try-catch.
To me this speaks of a poorly designed resource management system. As @alexd457 said, when a language uses exceptions to handle error states, resource management should be closely designed with it. Simply throwing the exception in the .use() block and catching that in a subsequent try-catch block underneath it is just dirty.
I’m not saying that it doesn’t work. .use() certainly works, and you can use it perfectly safely. I am saying the current system is not very good and needs to be improved, and as far as I’ve seen extending the language itself is far and away the best option for doing that. I kind of understand the idea that accomplishing it with the stdlib is easier to work with and undersatnd, but I disagree. Complex stdlib methods are not easy to work with, language constructs built specifically around these goals are typically much better suited. .use() is not a complex method by any means, but it’s simplicity brings it’s drawbacks.