@Throws doesn't work in my code, "Unresolved refer...

# announcements

[Sylvain Patenaude]

@Throws doesn't work in my code, "Unresolved reference: Throws". Do I need a special import to make it work?

[Holger Steinhauer [Mod]]

That is odd. It is part of the kotlin.jvm package. So no import should be needed. Do you have a valid Kotlin configuration?

[Sylvain Patenaude]

My code is multi-platform though, so this is probably the issue. I made another post in the #C3PQML5NU channel. Most of my code is common and this is where I would need to put the annotation @Throws. ☹️

[Holger Steinhauer [Mod]]

Alright, interesting.

[Sylvain Patenaude]

Ok, I found a workaround, thanks to @kpgalligan. Now I'm not too familiar with using @Throws. I know I can use it with specific exceptions, such as @Throws(IndexOutOfBoundsException::class) for instance, but can you use it without any arguments, simply @Throws? And does it mean that it covers for any kind of Exception in this case?

[robin]

You can use @Throws(Exception::class), which will allow any exception to be thrown, since in Java, every checked exception is a subclass of Exception.

[Sylvain Patenaude]

Ok, I will try this @robin. @Throws (no parameters) must not be valid because although it compiled, it didn't yield the expected result.

[robin]

The argument to Throws is actually not just one exception class, but an array of exception classes, all of which the function may throw. From that definition, I'd guess that giving the annotation no Exception classes means "The list of exception classes this function can throw is empty), which would just mean the same as "This function does not throw any exceptions", so in effect just does nothing.

[Sylvain Patenaude]

According to the doc, it wouldn't work for instances of RuntimeException or subclasses. But the exception we're interested in catching is IndexOutOfBoundsException, which is a subclass of RuntimeException.
Does someone know why there is this limitation?
EDIT: Link (https://kotlinlang.org/docs/reference/native/objc_interop.html#errors-and-exceptions)

[kpgalligan]

In Java, Error and `RuntimeException`are unchecked, and intend to signal that things are super not OK. Error I understand, as if you get OOM or a stack overflow, you’re probably not going to be able to catch or deal with them. RuntimeException is debatable, but I guess you’ll need a wrapper. Swift/objc don’t really do this as much. If you had range issues in objc you’d definitely need to be dealing with them prospectively. If you absolutely need to let `IndexOutOfBoundsException`throw rather than range check first, you’ll need a try/catch at the Kotlin/Objc border I guess.

[Sylvain Patenaude]

What do you mean by Kotlin/Objc "border"?

[kpgalligan]

@Throws(OurWrapperException::class)
fun someKotlinThing(){
  try{
    //Dangerous code
  } catch (t:Throwable){
    throw OurWrapperException(t)
  }
}

[kpgalligan]

Swift calls into that. It’s like a border between the two worlds.

[kpgalligan]

Some discussion of it in error reporting: https://github.com/touchlab/CrashKiOS

[Sylvain Patenaude]

Oh ok, it's near the border, but still on the Kotlin side based on your example.

[kpgalligan]

Well, I call that the border, as in that’s the last place in Kotlin you can do anything, but I don’t want to get into term definitions

[Sylvain Patenaude]

Ok, so I did the catch (Throwable) and re-throwing trick as suggested by @kpgalligan above. However, the caller in Obj-C has now a bunch of compile errors (see screenshot included). Is there anything else I need to do on my side (the Kotlin/border side)?

[kpgalligan]

You’ve got something else going on there

[kpgalligan]

Would need to see more of your setup. Does the kotlin build with gradle? If so, maybe we can isolate that to just Xcode’s config

[Sylvain Patenaude]

I'm not at work this week, so I don't have a Mac to test. The testing/using my SDK is done by some other party, so I could ask them some specifics, if need be.
But I'll say that before doing the catch/re-throw thing, they had no problem, at least at compile time. It's just that sometimes the SDK throws some runtime exceptions (such as IndexOutOfBoundsException) that are not catchable from iOS.

[kpgalligan]

“The testing/using my SDK is done by some other party” If you’re saying that you don’t actually run you code locally, I would imagine that’s a pretty difficult constraint to work under. That error looks like a linker issue. The catch/re-throw should make no difference for compiling the code, but this is a compile time issue.

[Sylvain Patenaude]

Yeah, they told me compile issue (maybe it was said in a broad sense), but that looks more like a linker issue. Still strange though, don't you think, since before the catch/re-throw adjustments it was working fine?

For what it's worth, here is the new exception class I added:

package com.mycompany.mysdk.exceptions

class ParsingException(innerException: Throwable) : Exception(innerException) {
}

[Sylvain Patenaude]

Ok, it appears the consumers of the SDK were using an incompatible version of Xcode. That would explain the errors...