Question

I would like to be able to determine, in case an exception occurs while the user is using my application, where exactly the exception took place. I’d like to do something similar ti printStackTrace() method. (So this is during build mode, not debug mode )

Currently I’ve put almost all my methods from all my classes inside a try-catch statement (each method has a try-catch statement which encompasses all it’s instructions) and i can, at this point, display the “tree” or stack of methods if an exception occurs. But is there a way to determine either a line number of something to more precisely indicate where inside the method the exception occurred? Similar to what is displayed when you use printStackTrace().

I’m not really used with Exception handling, what is the best practice for doing this and can in be done?

EDIT

And one other thing. When i use printStackTrace() during build mode, where does it display the content, because Logcat isn’t available? Can i retrieve that information and maybe do something with it?
OR
Even better, can i use getStackTrace() during build mode and convert the stuff there in String and maybe output it somewhere?

Answer 1

All the exceptions that are not handled by your code and make your app crash in release mode will appear in the android developper console, close to your app.

For this to work, you will need to retrace obfuscated stack traces.

About exception handling : I suggest you read this for instance. You are making a mistake about exception handling if you surround all your code by a try/catch block.

Exception handling is more subtile than that and is often influenced by design considerations (whether to treat exceptions locally or throw them back to the caller).

To sum up : in the core of your app : don’t treat exception but throw them or let them be thrown, using the throws clause of your methods signatures. In the upper layers, closer to the UI, treat exceptions with try/catch and if an error occurs, make sure your app is in a stable state and display some usefull messages to users.

More details (but not that much) :

• in the database layer : throw exception. You can still catch them to log them, but throw or rethrow them to tell caller that something went wrong.
• in the business layer : catch them, make sure your business/domain model is in a stable state and recovers from the error, and throw them back to the caller.
• in the UI layer : catch the exceptions and display some messages to users.