Develop Reference

How can I find out why my app crashes if logcat show no reason?

I have an app that processing some pdf files in background and suddenly it crashes with no 'caused by' description. Tried with real devices, new emulators, restarted pc and so on.
Never had something before and I don't know where to search for the root cause.
Edit: I found that problem was in a try/catch block
try {
val pdfReader = PdfReader(URL(it))
//process
pdfReader.close()
} catch(e: FileNotFoundException){
//process exception
}
So the problem was in wrong exception, when I switched to a more general exception, I could handle it and see error in logcat
try {
val pdfReader = PdfReader(URL(it))
//process
pdfReader.close()
} catch(e: Exception){
//process exception
}

If you are using iTextPdf it can sometimes throw NoClassDefFoundError for no reason as far as i have experienced. Maybe catching this Error instead of Exceptions could help you identify the problem. Like this:
try
{
// do stuff
}
catch (Error err) //or NoClassDefFoundError
{
System.err.println(err.getMessage());
}

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.

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) {}

Android debugging exceptions

I have been working with Eclipse/Android development porting a game from windows for about a month now.
But I have been frustrated with some aspects of this Environment.
When I get an exception, very rarely does the debugger stop where it needs to.
I have tried adding Exception breakpoints, this helps hit a few errors in relevant code but still very hit and miss.
Visual studio always stops execution in the closest entry point to the throwing of the exception, and I really miss that.
Even a minor
myArrayList[outOfBounds]
does not stop on the line that caused the issue.
I would like to know what experienced android developers do to track down the cause of exceptions quickly.

Put a try{ block around the statements that are going to generate the exception and then in the catch do something like
catch (Exception e) {
System.out.println("Test \"" + arg +
"\" threw a " + e.getClass() +
"\n with message: " + e.getMessage());
}

You can use try - catch block. Whenever any exception comes your catch block will be executed so you can put alert or message in catch block to track your problem or you can use Exception parent class to trace your bug.
try{
Your code to execute
}catch(Exception e){
e.printStackTrace();
}
This will give you error log in your logcat.

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?)