Remove custom NSErrorException
in favor of built-in ObjCErrorException
#666
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Instead of introducing our own
NSErrorException
to propagateNSError
s to Swift (that I introduced in #598), we change on approach to instead rely on the built-in (albeit internal)ObjCErrorException
via https://github.com/JetBrains/kotlin/blob/b05604058fa3c480030267629cc70cf180a1263d/kotlin-native/runtime/src/main/kotlin/kotlin/native/internal/ObjCExportUtils.kt#L274Previously, we needed to create a helper on the Swift side of things to extract the nested
NSError
details when throwingNSErrorException
s in our code:Downstream users had to rely on the helper extension to read the error details:
With this updated approach leveraging
ObjCErrorException
, the error in the Swift catch block is already anNSError
containing the correct error information. We can simply read the data from it, noError
extension required:This simplifies things for downstream users.
Using this updated approach, here's what I see when purposefully generating an error scenario (calling
registerFont()
on the same font multiple times):