Develop Reference

Error handling in the onCreate() method of activity android

I am new to android development. In the overriden onCreate() method of my activity, I perform some operations. For ex. check if SharedPreference is already available and then route to other activity. How do I perform exception handling on this onCreate() method. Is it the right way to wrap the contents in a try catch and display the error dialog on exception?
If the exceptions are not handled properly, in my case the onCreate() method, the app crashes with message:
Unfortunately your application stopped working
On searching in the internet, I found that UncaughtExceptionHandler could be used to handle it. Any sample implementation and how to call it from all my activities would be helpful.

THat's the wrong way to go about it. Instead, go into your logcat. Read the stack trace of the exception. Figure out what you did wrong. Fix it. Just catching exceptions is a horrible practice unless you're catching a specific exception for a specific reason- its very unlikely your app is in a state where it can continue correctly. Don't be lazy, track down your bug and fix it.

With something like this you can catch a generic Exception in your onCreate() method:
#Override
protected void onCreate(Bundle arg0) {
super.onCreate(arg0);
try {
// do whatever you need
} catch (Exception e) {
e.printStackTrace();
}
}
Exception catching can be used with many goals. An interesting one is to catch particular expected exceptions to fix some problems (for example setting a generic value into a variable otherwise null after occurring an error).
The general purpose however is to avoid that an error causes a problem or in the worst case a crash of your application. Depending oh what kind of software you are developing, a crash may represents a little problem (like in an Android app), a very big one (like in airplane's softwares or power plants' softwares).
We can identify two kind of exceptions.
The first type are those exceptions specific to definite problems. They have to be declared into methods signature, so you are encouraged or obbligated to manage these exceptions and their relative problems. These exceptions represent an error that should probably occur during particular code execution, like a parsing error, or an input output error. For this type of problems we have particular exceptions, to catch and easily manage them (for example as previously said to init a variable with a default value after an error).
The second type of those exception represents instead some generic problems that can occur during program execution. They are a big and generic set and generally their probability of occurring is low. For this reason you are not obbligated to manage them. The main example of this type is the general Exception class.
So an catching an Exception is not the right approach to solve a bug, as suggested by Gabe Sechan.
Catching a generic Exception in the main() Java method can be a way, for example, to show a default human readable error to the user if nothing else is available.
Or could be a way to keep the failing of the current operation reducing crash probability.
Now, in Android we can't act directly on the main() method. onCreate() method is executed and exited so catching here a generic Exception has no much sense. Obviously it depends also on what you do in your onCreate() method and what you want to do if an error occurs. You could do some strange stuff (is very defined what you should do in the onCreate() method) and you could need to manage a big set of problems only showing an error, so it has more sense catch only a generic Exception than a lot of particular exceptions to make the same thing in each catch block.
If you want to achieve this goal (a message showed for all the errors occurred during onCreate() execution, made Activity by Activity) this is the right approach.
If instead what you want to achieve is to intercept all of the errors that are generated during all of your app execution, a good approach could be the UncaughtExceptionHandler, that act similarly to catch a generic Excepetion into a Java main() method. At this level an interesting approach is described here.
For more infos about exceptions you can read this and this.

Android: Arrayoutofindexbounds with Thread

I have a little problem with my code. I keep getting an arrayoutofindexbounds with the following code:
public boolean checksouth(int r,int c, int numofwords) {
if (south==false)
{return false;}
computer_find=0;
for (int x=0;x<=(numofwords-1);x++)
{
if (worduniverse[(r-x)][c]==computer_words[x]) **bold**<=Problem arises here>
{
computer_find++;
}
}
if ((computer_find==numofwords)&&(numofwords!=0))
{
r_computer=r;
c_computer=c;
direction_computer=2;
highlight_num=numofwords;
return true;
}
return false;
}
My objective is to create a Word search protocol that would not use the UI. When I put the code into the UI the system kept giving me an ANR.
However the code, while in UI, never gave me an Arrayoutofindex. The arrayoutofindex only occurs once the code is called from another thread. I cannot understand this. Any help would be appreciated.
I must point out that the code accurately worked outside the Thread. When it was put into another thread it gave me false results. I need the thread in order to reduce possibility of ANR in my app.
The Logcat output simply points to the location I have highlighted.

You can use AsyncTask insted :
http://developer.android.com/reference/android/os/AsyncTask.html

Wow, I like to thank all for the help. I achieved my objective by simply including all code into one method. Was a lot faster and did not give me an ANR.
I was always getting an ANR because I had multiple methods to help me do brute force word alogrithnm. Weedled the methods down to one and the search took less than 1.5 seconds on an Android phone.

Try-Catch: Is it OK to leave applications with handled exceptions?

I am still fairly new to programming, so there are some things I learn from observing but do not fully understand. The Try-Catch is one of these things. From what I have researched, the try statement allows me to define a block of code to be tested for errors, and the catch statement allows me to define a block of code to be executed if an error occurs in the try block.
I get that. And I have tried to use Try-Catch in situations where I was receiving exception errors that crashed my applications. The Try-Catch seemed to prevent (stop) the crashing. But here is my question, is it OK to have an application that constantly catches an exception error?
For example, I am working with EditText widget. I want the input values for the EditText to represent currency, so I applied android:inputType="numberDecimal". The issue I learned with this is that this attribute allows any number of values after the decimal. This is when I came up with an idea of updating the EditText programmically with the proper format, using something like DecimalFormat.
I am not posting my entire code, but here is the piece that I am curious about.
#Override
public void onTextChanged(CharSequence s, int start, int before,
int count) {
// TODO Auto-generated method stub
DecimalFormat format = new DecimalFormat("0.00");
if (etBill.getText().toString() != null &&
etBill.getText().toString().length() > 0) {
try {
doubleBill = Double.parseDouble(etBill.getText().toString());
strFormatted = format.format(doubleBill);
Log.d(TAG, "unformatted(" + doubleBill + ")" +
" // formatted(" + strFormatted + ")");
//etBill.setText("$" + strFormatted, TextView.BufferType.EDITABLE);
etBill.setText("$" + strFormatted);
} catch (NumberFormatException nfe) {
Log.e(TAG, "FloatingPointParser.parseDouble error");
}
} else {
// values in editText were deleted; hardcode value
doubleBill = 0.0;
strFormatted = format.format(doubleBill);
}
}
And here is the exception error I catch every single time I input a value into my EditText widget.
So my question is, is the Try-Catch a method for me to correct my errors? Is it OK to catch exception errors, such as this NumberFormapException through the life of an application running? Am I using this right? Thanks in advance!

NumberFormatException is a runtime exception and you are catching it correctly. However, instead of just printing something to let you know you have caught it, you should either handle it by re-running through your code or pass the exception up the stack. For example, if a user inputs a number and then this exception is caught, you could prompt them to re-enter a new number. If the number that is throwing this exception is not provided by a user, but by your code, then it indicates you have a logic error somewhere and should fix that to prevent this exception from being thrown in the first place.

In general the exception mechanism should be used for exceptional circumstances - something that usually shouldn't happen. If you have an exception that's being thrown every time you enter a value, that's sort of abusing the mechanism. Usually there's a better way that doesn't involve exceptions. In some cases though, the exception mechanism is the cleanest way of dealing with the situation.
Here's a quote from Effective Java: Programming Language Guide by Josh Bloch:
"Use exceptions only for exceptional conditions. That is, do not use exceptions for control flow, such as catching NoSuchElementException when calling Iterator.next() instead of first checking Iterator.hasNext()."

Exception handling is not only an art but the subject of much discussion/debate. I will try to address the broader points without incurring anyone's wrath.
There are two kinds of exceptions--fault exceptions and contingency exceptions. Fault exceptions are unrecoverable like being unable to connect to a web service that is supposed to be there for your app to function. You log those in your catch block and rethrow to let them bubble to some fault handler. Contingency exceptions are what you described with the number format issue--stuff you can recover from. In this case, you handle things completely in the catch block. You allow the app to recover by prompting for a new input, for example.
By the way, none of that is my own. That strategy comes from Barry Ruzek.
Then there is the issue where people dislike using exceptions for flow control--for good reason. In your case, that would mean using a regular expression in an if statement, for example, to test number format rather than using a potential exception-generating operation. You generally don't want to use exceptions for normal control flow, but you also need to be careful not to let ideology trump a simple solution. There is a balance you will learn with experience.
So you should recover from the exception in your catch block. Or use a different non-exceptional mechanism entirely to manage control flow.
Hope that helps.

Using Try catch in programing is fair enough. But handling errors is different issue. Try catch is just to way catch erronious conditions which can occur in ur program but u may wish to catch it or leave its up to you. Simple example is age is not allowed as floating point number but height is allowed both floating point and decimal number.

Android & SQLite - Occasional error 'unable to close due to unfinalised statements'

I seem to get the above error every so often in (an insert heavy) part of my code. I know normally this means there is an open Cursor within the connection but I have been through checking all my cursors are in try finally blocks and closed.
Also in logcat the error reads 'sqlite3_close(...) failed: 5 which I think means the database is busy?
The error can be 'ignored' if I add the following code to my finally block where the database connection is closed.
finally
{
writer.endTransaction();
boolean successAtClose = false;
while(successAtClose == false)
{
try
{
writer.close();
successAtClose = true;
}
catch(Exception e)
{
e.printStackTrace();
}
}
dbConn.releaseLock();
}
When stepping through the code above the 'e.printStackTrace()' is hit once but on the second attempt the 'writer.close()' does not throw an error.
Just to reiterate, this problem doesn't even happen every time the code block runs, the same data can be inserted say 5/6 times and only throw the error on one of these times. In addition the error does not reoccur straight away after happening once but continues to pop-up at random intervals.
Does anyone know why this might occur? Or a better way to recover from this than the finally code above? (Since it will take me a long time to add this to all my database code.)
ADDED:
Database is opened with a custom SQLiteOpenHelper which is extended to use a reentrant lock to ensure only one thread accesses the database at any one time. So the start of the code is like:
MyDatabaseHelper dbConn = MyDatabaseHelper.getDatabaseAccess(c);//await availability/lock the database here
SQLiteDatabase writer = dbConn.getWritableDatabase();
try
{
writer.beginTransaction();
//do inserts
writer.setTransactionSuccessful();
Get database access as follows:
public static MyDatabaseHelper getDatabaseAccess(Context c)
{
l.lock();
return new MyDatabaseHelper(c);
}
As a further test I have further added a Thread.sleep() call to the finally code (in my case of 12 seconds), before the close() but after the endTransaction(), that seems to have stopped the error and confirm it is not a case of an open cursor, but I would rather not rely on a timer. If there is a better way, perhaps to pre-check whether the database is busy, please share.

If you are using SQLiteStatement or SQLiteQuery objects to work with your database you need to make sure they get closed out as well. If it's SQLiteClosable you need to close it.

This mainly happens when you haven't closed the cursor, meant certain references to the database were invalid.
refer ths link Android SQLite Exception: unable to close due to unfinalised statements

The workaround is incorrect. close() decrements a reference counter and only when the counter hits exactly zero is the actual resource disposal i.e. sqlite3_close() attempted. On the second call the counter will be negative and the call will be a no-op.
You are correct that error code 5 is SQLITE_BUSY.
Now to address the actual problem, please provide some additional details, such as how you open and configure the database and how you begin your transactions.

Exiting from Xml.parse when match is found

I'm using the Android SAX parser to search for entries in a rather large (6MB) XML file. I'm basically using a derivative of the code shown in listing 8 here. The question I have is how do I stop parsing once my match has been found? The code shown continues parsing through the end of the file but I want to stop before then. Is this possible or do I need to use something other than SAX (e.g. XmlPullParser?)

Generate an ArithmeticException and catch it !
if (condition) { int a=1; a/=0; }
...
try {
Xml.parse(this.getInputStream(), Xml.Encoding.UTF_8, root.getContentHandler());
}
catch (ArithmeticException e) {
return true;
}
That's awful but it works...

Well DiskCrasher,
Every Sax parser will work till the end generally, But if you still want to quit it while its in the middle of the work, you can always check condition and use the return statement.
But Far better way of selective parsing would be to use the XML PullParser, Coz this parser will in general work on the fly and give you data without loading the whole file. This way you can check condition and exit the loop anytime without even need to use large memory chunks...
Hope this is somehow helpful to you!!!

You can throw an exception when you get a match. The exception can capture the match info and will be propagated to the original parse() caller. Catch the exception and test whether it is one based on getting a match or a true parsing error and process accordingly.