Kotlin/JVM has `@Throws`. Does Kotlin/JS have some...
# multiplatform
b
Kotlin/JVM has
@Throws
. Does Kotlin/JS have something like that?
g
No, this is JVM only annotation, it need only to mark methods for Java Maybe stdlib should mark
Throws
as optional annnotation for other platfroms, there is API now for this
sure
@Throws
used only to add checked exception to some method. Kotlin doesn’t have checked exceptions, so from Kotlin code
@Throws
is ignored (even on JVM), but Java user must handle it. JS doesn’t have checked exceptions, so this annotation will do nothing on JS side, even if it will be added as optional expect annotation
d
Correct. This is true whether or not you have
@Throws
or not.
g
Use Result or any other similar wrapper for exceptions if you really want to handle every possible exception and don't forget to do that
b
I'd rather keep
Result
to asynchronous use if at all possible
g
But Result (or any similar Try monad implementation) has nothing with asyncronous, it's not even lazy and works perfectly for sync calls as well, so if you worry about exception I believe it is good solution
b
Result
also doesn’t throw up compiler warnings when I’m making library calls that might throw JVM exceptionthrowables, which is my primary concern
g
doesn’t throw up compiler warnings when I’m making library calls that might throw JVM exceptionthrowables
What do you mean? But without Result do you have warnings about catched exception? Never see this
Also I don’t understand why do you need any compiler warning in case of Result, this is completely safe by the nature of such approach with Try-monad, when you have some container for exception which never can be thrown without explicit code
b
Sure, with Result the compiler handles it all through the type system. Even so, I hate making what I think is a save library call only to find out that it crashes for 1% of my users after I send it out. I know that a stronger solution might solve this. Anyway, this has gotten out of scope. I’ll put it all in a blog post or something.