I am a bit confused with throwing custom exceptions in Swift 3.
In C++ I can do this to immediately stop the process in the method, throw an error and handle it without proceeding further.
void foo()
{
try
{
if (a > b)
{
throw MyException();
}
DoOtherStaff();
}
catch (const MyException& e)
{
HandleError();
}
}
I am trying to implement something like this in Swift 3
enum MyError : Error
{
case myError(String)
}
func foo()
{
do
{
if (a > b)
{
throw MyError.myError("My error message");
}
DoOtherStaff();
}
catch
{
HandleError();
}
}
But it tells me me that the error is not handled because the enclosing catch is not exhaustive. Is there a way to handle it?
Thank you!
There is nothing wrong a priori with the code you showed. As a proof, just copy and paste the following into a playground (or into a class definition in an actual project):
enum MyError : Error {
case myError(String)
}
let a = 1
let b = 2
func foo() {
do {
if a > b {
throw MyError.myError("My error message")
}
doOtherStuff()
}
catch {
handleError()
}
}
func doOtherStuff() {}
func handleError() {}
That compiles and runs fine in the playground (though of course it doesn't do anything). Observe that all I did different from the code you gave was to "fill in the blanks", i.e. provide declarations of all the terms you referred to.
Related
Let's have a function which just computes something in try-catch and returns the result:
private fun compute(): String {
return try {
// do some computation
// ...
"result"
} catch(t: Throwable) {
throw RuntimeException("Uups") // <-- GOAL: extract this to a dedicated method
}
}
I would like to extract the throw declaration to a separate function (which contains the my boilerplate code).
However, I'm unable to compile such setup in Kotlin.
A simplistic (and still uncompilable) version of the described problem:
private fun compute(): String {
return try {
// do some computation
// ...
"result"
} catch(t: Throwable) {
justThrow() // <-- NOT COMPILABLE, STRING EXPECTED
}
}
#Throws(RuntimeException::class)
private fun justThrow() {
// some boilerplate code
// ...
throw RuntimeException("Uups")
}
How write justThrow() method in Kotlin so that the whole code is compilable?
In Java this case would be detected by a compiler (I suppose).
Kotlin version: 1.4.21
You can declare the return type of your method as Nothing. This type can be used for any method that does not return normally. That might be because it will always throw an exception, or simply never returns at all, for instance because it contains an infinite loop.
private fun justThrow(): Nothing {
// some boilerplate code
// ...
throw RuntimeException("Uups")
}
I am learning Kotlin and MockK. I have seen how to verify that a method was called and how to check the result. But how would I check, that the method has thrown an exception?
Sorry, I found it: assertFailsWith<EceptionClass> { methodCall() }
This is my approach, hope its helping you
class TestClass {
fun testVerify() {
throw Exception("exception")
}
}
#Test
fun mockTest() {
try {
TestClass().testVerify()
}
catch (e: Exception) {
assertEquals(e.message, "exception")
}
}
I'm trying to display emails of users stored in firebase database.
I've this below code
snapsListView = findViewById(R.id.snapsList)
val adapter = emails?.let { ArrayAdapter(this, android.R.layout.simple_list_item_1, it) }
snapsListView?.adapter = adapter
auth.currentUser?.uid?.let { FirebaseDatabase.getInstance().getReference().child("users").child(it).child("snaps").addChildEventListener(object: ChildEventListener{
override fun onChildAdded(snapshot: DataSnapshot, previousChildName: String?) {
emails?.add(snapshot.child("from").value as String)
adapter?.notifyDataSetChanged()
try {
for(x in emails!!){
Log.i("Emails", x)
}
} catch (e: Exception) {
e.printStackTrace()
}
}
Emails are present in the database and as per the hierrarchy also, users-> uid->snaps and snaps contains the email in "from"
Don't know what is causing this error, or how do i resolve this.
Always getting null pointer exception
By using !! operator you have asserted that emails is not null. However, Kotlin thrown runtime exception because emails is null actually. Consider replacing !! with safe-access:
emails?.let { for (x in it) Log.i("Emails", x) }
According to the source of Closable.use, if an error occurs, an exception will be thrown.
public inline fun <T : Closeable?, R> T.use(block: (T) -> R): R {
var exception: Throwable? = null
try {
return block(this)
} catch (e: Throwable) {
exception = e
throw e
} finally {
when {
apiVersionIsAtLeast(1, 1, 0) -> this.closeFinally(exception)
this == null -> {}
exception == null -> close()
else ->
try {
close()
} catch (closeException: Throwable) {
// cause.addSuppressed(closeException) // ignored here
}
}
}
In most examples of Closable.use, try-catch is not used as shown below.
Why isn't error handling needed? Is it safe?
BufferedReader(FileReader("test.file")).use { return it.readLine() }
This line
BufferedReader(FileReader("test.file")).use { return it.readLine() }
is not safe. Reading and closing the reader can both throw IOExceptions, which are not RuntimeExceptions (caused by programming errors). That means leaving them uncaught exposes your app to crashing from things outside your control.
Since Kotlin doesn't have checked exceptions, the compiler won't warn you about this. To do this safely, you need to wrap it in try/catch. And if you want to handle read errors differently than close errors, you either need to have inner and outer try/catch statements:
try {
BufferedReader(FileReader("test.file")).use {
try {
return it.readLine()
catch (e: IOException) {
println("Failed to read line")
}
}
} catch (e: IOException) {
println("Failed to close reader")
}
or wrap the whole thing and extract any suppressed exceptions, but then its cumbersome to distinguish between them:
try {
BufferedReader(FileReader("test.file")).use { return it.readLine() }
} catch (e: IOException) {
val throwables = listOf(e, *e.suppressed)
for (throwable in throwables)
println(throwable.message)
}
But in practice, you're probably not going to react differently to various IOExceptions, so you can just put the one try/catch outside.
We see from Kotlin documentation what is the purpose of the use function:
Executes the given block function on this resource and then closes it
down correctly whether an exception is thrown or not.
This function closes the resource properly if the block function completed successfully or threw an exception. It is your responsibility to handle the result of the block function.
If an exception was thrown and there is a way to handle it and proceed with code execution, use a try/catch. If there is nothing to do about it and control should be passed to the caller, it is not necessary to use a try/catch.
I am trying to get my head around error handling in rxjava. I thought if i combine a stream of observables for instance in a zip() function that errors emitted by the observables within the zip would break the sequence and bubble up to the subscriber onError function. However the only error caught there are the ones emmitted in the BiFunction. Errors emitted up the chain causes the system to crash. when i add onErrorReturn to the observable and return a fallback value the system still crashes. So for me that does not work as I expected. What am I missing?
private fun getOneThing (): Single<String> {
println("getOneThing")
if (isOneBadCondition) {
throw Exception() //causes crash
} else {
return Single.just("a string thing")
}
}
private fun getAnotherThing(): Single<Boolean> {
println("getAnotherThing")
if (isAnotherBadCondition) {
throw Exception() //causes crash
} else {
return Single.just(true)
}
}
private fun createSomethingElse (): Int {
println("createAnother")
if (isBadCondition) {
throw Exception() //is handled onError
} else {
return 2
}
}
fun errorHandlingTest() {
Single.zip(
getOneThing(), //if I add onErrorReturn here it is not called after error
getAnotherThing(), //if I add onErrorReturn here it is not called after error
BiFunction<String, Boolean, Int> { t1, t2 ->
createSomethingElse()
}
).subscribeBy(
onSuccess ={ println(it) },
onError={ it.printStackTrace() }) //only error thrown by createSomethingElse() are caught here
}