My question is not very specific to kotlin-native, but since I'm writing a KN library I would like to get some feedback from the people here: In the bindings I'm writing I'm wrapping lots of C functions that can "throw" errors. I would like to avoid having multiple signatures for every "throwing" method so I need to choose which signature I'm going to generate: I can either return a

Result<T>

to make the the error explicit in the signature, or I can add a

@Throws

annotation and just throw the exception. Currently I'm favoring the

Result<T>

approach but it has some issues (like the Exception type not being generic). Any opinions on this?

I would not „fight“ against the language and would use @Throws

The thing I'm worried about with using

@Throws

is that a lot of these methods can frequently "throw" and aside from the annotation on the signature there is no other indication that it can. AFAIK Intellij does not warn when calling a

@Throws

method that does not handle the exception. Given the tendency for many developers to not read the docs I'm afraid many of these will be missed leading to frequent runtime crashes (not ideal in a GUI library). I put "throw" between quotes because the methods I'm talking about are generated bindings from C code, which use an error pointer argument that gets populated when the C function returned early with an error.

I absolutely understand your use case. Kotlin does not have checked exceptions by design and wrapping everything in a

Result<T>

isn't a common practice. The mapped Java File APIs are similar:

File("foo.txt").writeText("foo")

This could also fail with IOException, but there is no hint/language design to explicitly catch the exception. But Kotlin's design is also pragmatic. If it does work for you, use your API design, in this case, I would use your own

Result

class to provide more information.

Thanks for your input, I'm still going back and forth on both approaches.

This is probably a good question for #library-development. I have been in this situation and what I/we came up with was that there was no single way to handle errors across all functions in a library. Maybe your library is very small or specialized, but a single approach for all functions probably won't be appropriate for all use cases or functions. Some combination of the two approaches made sense for us for how different functions are used. We also incorporated a third category for being lenient with exceptions, the

...OrNull

variety of functions which catch all exceptions and return null.

Yes, I agree, not all errors should get the same treatment. However we are currently generating Kotlin code for a large amount of libraries driven by gobject introspection GIR files so there is a large amount of error-throwing methods to cover with varying use cases and for most of them we don't know the exact semantics, only that they "throw". Currently it generates 350+ error-throwing methods and there is a significant number of methods that are skipped for other reasons (like argument or return values for which we don't have conversions yet) Hence, we need to find a general solution that works for most cases, with the possibility of manually providing alternative error handling implementations for specific methods/functions but that is a manual process. The reason the

Result<T>

approach looks interesting (which is the current implementation) is that it provides some flexibility to the library user. The

Result<T>

class provides some utilities like

getOrNull()

,

getOrThrows()

.