Develop Reference

Kotlin socket property getter should I check for exception?

I'm writing an Android bluetooth client application in Kotlin. Now I'm trying to get OutputStream from a connected socket.
When writing in Java, I have to check for IOException:
OutputStream stream;
try
{
stream = socket.getOutputStream();
}
catch(IOException e)
{ ... }
But in Kotlin, it seems that I can directly get the object through getters
val streamOut : OutputStream = socket.outputStream
The question is should I check for IOExecption as well? Or is the outputstream already set in the socket.connect() step?

Java is very strict about exceptions. Whenever you write a code that could throw an exception, you need to either catch it or mark your own method with throws. Kotlin does not require this, you are not enforced to catch exceptions, but that doesn't mean it will auto-magically handle errors for you or something. socket.outputStream may throw an exception, so you need to be prepared for such a situation. If you omit catch {} block, then in the case of an error, it will propagate through the call stack.

How to handle different kinds of errors in Retrofit Rx onError without ugly instanceof

I would like to know your ways to handle different kinds of errors (like http exceptions, no internet connection exceptions etc) in retrofit Rx onError without using instanceof like it's proposed here: How to handle network errors in Retrofit 2 with RxJava or here: Handle errors in Retrofit 2 RX
In kotlin I will simply make some extension functions for each kind of throwable to do whatever I want.
But I am forced to use Java in the project. Any nice suggestions?
is the approach to build some kind of error handler like this:
public interface ErrorHandler {
void handleError(Exception e);
void handleError(HttpException e);
void handleError(NullPointerException npe);
}
good? I know it is not because every time i need to handle another specific error I am forced to change interface, so it is violation of Open Close Principle. But I can't figure out any solution .
cheers
Wojtek

The compiler determines which method to call, rather than the VM. So the class you've described won't solve the problem unless you check instanceof first and cast the paramter to the correct type. Otherwise you're going to get handleError(Exception e) every time.
But I wanted to create an answer not for that reason, but to argue that having only one error handler is actually preferable in many cases, not a liability. Oftentimes in java we end up in awful situations like this:
catch (NoSuchAlgorithmException e) {
throw new IllegalStateException("No such algorithm: RSA?", e);
}
catch (NoSuchProviderException e) {
throw new IllegalStateException("No such provider: " + ANDROID_KEYSTORE_ID, e);
}
catch (InvalidAlgorithmParameterException e) {
throw new IllegalStateException("Bug setting up encryption key for user credentials: ", e);
}
catch (KeyStoreException e) {
throw new IllegalStateException("Bug setting up encryption key for user credentials: ", e);
}
catch (IOException e) {
Log.w(TAG, "Exception setting up keystore for user creds. They won't be stored.", e);
}
catch (CertificateException e) {
Log.w(TAG, "Exception setting up keystore for user creds. They won't be stored.", e);
}
Having only one error handler gives us the ability to lump many types of exceptions together. You can see in this code, there are exceptions that should never be thrown, exceptions that can really only be the result of a bug in the code, and legitimate exceptional states that we need to handle. I find this messy, and would prefer to say:
if (e instanceof NoSuchAlgorithmException || e instanceof NoSuchProviderException) {
Log.wtf(TAG, "What the heck is this?", e);
throw new IllegalStateException("This is some kind of weird bug", e);
}
else if (e instanceof IOException || e instanceof CertificateException) {
// This can happen sometimes, track event in analytics and perhaps
// try some alternative means of credential storage.
}
else {
// At least here the app won't crash if some unexpected exception occurs,
// since we're trapping everything.
}
I don't think it's such a bad thing to be able to lump unexpected failures together and handle them in a more user friendly way than crashing the app. Even if it's just a bug, better to track it in your analytics framework behind the scenes than bomb the user out of the app. So many crashes in Android apps are actually completely recoverable, but we don't go around catching Throwable in every try/catch statement because it's a lot of extra code.

The proper OOP way to avoid chained ifs or catches is polymorphism. You can define several custom exception classes exposing common interface that is enough for a single handler to process.
Suppose you need to divide errors in two groups: recoverable and not recoverable. Then your base exception class (or interface) shall have abstract method isRecoverable() that you override in each subclass. Then there will be only one if in your handler: if (e.isRecoverable()) { ... } else { ... }.
The downside is that you have to wrap all standard exceptions into your custom ones at places where they are thrown (you have to catch them).
The right choice will greatly depend on your task, though.

Hide thrown exception messages on Android

Is there a way to block the displaying of thrown exception messages (with all the stacktrace and everything) for an android app ?
EDIT:
Well, I know I can use try/catch block to do that that's not what I want.
Is there like a way to specify that in mafinest file or maybe in project settigs or smthng ?

you can wrap your code in try catch
try {
// code that might throw an exception
} catch (Exception e) {
//don't print the exception
}

How to handle exception and prevent crashing app

I am using the Amazon AWS SDK to download images from S3. Occasionally, when an image is not found an exception "AmazonS3Exception: Status Code: 404" is thrown. However, this seems like an exception which should not crash the app. How can I handle this exception so that it does not crash the app? Apologies, Im a noob to Java & Android.

To follow up on type-a1pha's answer:
If you want to handle an exception gracefully, you would use a try-catch statement. It works something like this:
try {
// Here you put the code that may throw an exception
} catch (AmazonS3Exception e) {
// Looks like we errored out, log the exception and
// tell the user that we 404'd
Log.e(TAG, "Error fetching file from Amazon S3", e);
Toast.makeText(context, "Error 404 while fetching file: file not found", Toast.LENGTH_SHORT).show();
// Insert any other code you need here to recover from the error
} finally {
// Note that the finally part is optional but useful if you want
// to do something after the try-catch statement is finished
// for example, if you were using an inputStream:
inputStream.close();
}

try{
//code throwing exception
} catch (AmazonS3Exception) {}

How to catch IOException Error in eclispe for Android?

I want to catch an IOException Error and want to show it in the form of toast for android application development. But when ever i apply catch(IOexception e), after try block it says to throws (throws IOException) with function name after which i am to catch error message.. Please Provide Some assistance....

May be you desire to 'throws' catched exception above the call stack, and next, catch and process all exception in one place (or 'layer') of code?)