is there a better way of declaring that my functio...
# announcementsh
Hexa
10/19/2018, 9:16 AMis there a better way of declaring that my function will throw an exception without using a annotation? Example I use the`Throw` annotation
Copy code
@Throws(NoSuchAlgorithmException::class)
private fun generateKeyPair(): KeyPair {
}d
diesieben07
10/19/2018, 9:18 AMNo there is not. Since this feature only exists for Java interoperability there is no direct language feature for it.
h
Hexa
10/19/2018, 9:18 AMokay so there is no Kotlin way of doing this at all?
d
diesieben07
10/19/2018, 9:19 AMNo. Since Kotlin does not have checked exceptions there is no need for it. What are you trying to achieve?
h
Hexa
10/19/2018, 9:21 AMjust trying to convert java code to kotlin
Hexa
10/19/2018, 9:22 AMso I can just get a way with using this
Copy code
private fun generateKeyPair(): KeyPair {
}d
diesieben07
10/19/2018, 9:22 AMYes.
👍 1
diesieben07
10/19/2018, 9:22 AMUnless you want to call the function from Java, in which case you should keep the
Throwsh
Hexa
10/19/2018, 9:31 AMwhat happens when I call
generateKeyPaird
diesieben07
10/19/2018, 9:32 AMExceptions in Kotlin behave like RuntimeExceptions in java.
diesieben07
10/19/2018, 9:32 AMIf nobody catches them, they will end up in the thread's UncaughtExceptionHandler
u
ursus
10/19/2018, 2:31 PMthis always bothered me, since it hides for example io exceptions when working with files etc.
d
diesieben07
10/19/2018, 2:44 PMIt solves more problems than it creates imho
s
Sam
10/19/2018, 2:48 PM@ursus I had the same question a while back, check this response from Roman
Sam
10/19/2018, 2:48 PMSam
10/19/2018, 2:49 PMIn my case, i opted to have a Type convey the result or error Result<T> or something like that
Sam
10/19/2018, 2:50 PMCallers of my API understand the error possibility while trying to handle the success case
u
ursus
10/19/2018, 2:51 PM@diesieben07 @elizarov while I do agree with you, modeling the error into return type is best, even kotlin std functions for Files do throw
d
diesieben07
10/19/2018, 2:53 PMYes, they do throw. But checked exceptions bring all kinds of problems.
Kotlin uses lambdas and higher order functions heavily. If you have checked exceptions, you cannot call any "functions that throw" inside those lambdas, because the lambda itself does not throw (unless you catch the exception right there, in the lambda).
diesieben07
10/19/2018, 2:53 PMThat is one reason for unchecked exceptions.
u
ursus
10/19/2018, 2:54 PMright, but then the std api is wrong, i.e. it appears File.readBytes() wont crash, I need atleast a lint or something
d
diesieben07
10/19/2018, 2:55 PMDefine "won't crash".
diesieben07
10/19/2018, 2:55 PMIt won't crash, unless there is an IOException, which is an exceptional state.
u
ursus
10/19/2018, 2:55 PMyes, but expected exeptional state
ursus
10/19/2018, 2:56 PMonly unexpected things should crash imo
d
diesieben07
10/19/2018, 2:56 PMWhat classifies "expected"? Is "we ran out of memory" unexpected?
u
ursus
10/19/2018, 2:57 PMDepends on the domain. Would you crash the app if your network request failed?
d
diesieben07
10/19/2018, 2:57 PMNo, so I add
catchu
ursus
10/19/2018, 2:58 PMyes, but you dont know to do that unless you look at source
d
diesieben07
10/19/2018, 2:58 PMIf I am reading a file, I know that that can fail.
diesieben07
10/19/2018, 2:59 PMExample: I am reading from an
InputStreamByteArrayInputStreamdiesieben07
10/19/2018, 3:00 PMStuff like this cannot be (reasonably) exposed in the language, this needs to be handled through documentation.
Look at any decently sized Java application and you will see stuff like this:
Copy code
try {
// stuff
} catch (IOException e) {
throw AssertionError("impossible");
}u
ursus
10/19/2018, 3:00 PMthats just a coincidence for Files, pick any other custom api
ursus
10/19/2018, 3:01 PMIm not arguing for check exceptions, Im arguing for tooling to not forget handling expected errors, to which you have no knowledge of unless you look at source / doc; since the world is not ready yet to abandon them
d
diesieben07
10/19/2018, 3:04 PMOkay, but then you have the same problem. How is the IDE supposed to know that this error will be handled further up the call stack?
u
ursus
10/19/2018, 3:05 PMI see your point that @Throws and doc is the same thing which can be out of date or forgot
ursus
10/19/2018, 3:06 PMmaybe some static analysis for "throw" keyword?
d
diesieben07
10/19/2018, 3:06 PMI am not a tooling expert, not sure how feasible that is
u
ursus
10/19/2018, 3:07 PMme neither but Ive forgot to add try catch in kotlin few times already
2 Views