[android-developers] Re: Sqlite Error
Which one to use is a matter of taste and convenience. Just make it as
easy on yourself to do it as possible, so you'll always do it!
That IOException in stream.close() is very important. Consider a
buffered stream. Until you do a close(), some of your output is still
in your buffer. If that output can't be written, you'll get an
IOException, so you're not fooled into thinking your output succeeded
and your data is safely in the file.
It's not just buffered streams, however, because buffering can happen
anywhere -- underlying libraries, operating system, network, driver,
etc. Until that close successfully completes, IO errors are are still
possible, and may indicate that your data was not successfully
written.
Generally, you want to handle IOException at a higher level than the
try/finally that does the close. Often, it should be in a different
method entirely -- one where you can do something about it -- retry,
report the problem to the user, etc.
In fact, if there's not a specific strategy at hand for dealing with
an exception, it should be handled at as high a level as possible.
Java's check/unchecked exceptions are a bit unfortunate, in that
regard. It's often better to wrap an exception in a RuntimeException
and rethrow, than to either try to handle it locally, or to change
your method signatures by adding a 'throws IOException' all over the
place.
Swallowing exceptions is probably NOT what you want your wrappers to
do. Not unless they're either very far out in your stack, or are also
implementing a specific recovery strategy. (Returning null or false is
generally not the best way to do that!)
I have, several times now, written a WrappedException class that
largely hides the fact that it's not the original exception, but is an
unchecked exception. Let's say you've got some code that throws
either SQLException or IOException. It may also throw
FileNotFoundException (which is an IOException), and this is declared
in your method. Rather than duplicate the two catch clauses, you can
write:
try {
.. code that is declared to throw SQLException and IOException ..
} catch (Exception ex) {
throw new
WrappedException(ex).rethrow(FileNotFoundException.class).rethrow();
}
If it's a FileNotFoundException, the first rethrow will rethrow the
original exception (ex).
If it's a RuntimeException or Error the second rethrow throws the
original exception (ex).
If it's an InvocationTargetException or NoClassDefError or a few
others where you never want the immediate exception, the second
rethrow thows the cause exception (ex.getCause()).
Unfortunately, I've always done this for employers, so I don't have a
full implementation to hand out. I should recreate it soon, however.
This approach gives you a consistent way of dealing with checked
exceptions you're not prepared to deal with in the current context.
Swallowing them, or even logging them, hides bugs.
Generally, you shouldn't print or log them at the deeper levels,
either. That should generally be done at the outermost level, where
they're really handled, so they only get logged once.
On Feb 8, 5:48 pm, Jason Proctor
wrote:
> indeed -- i did investigate moving to this pattern, but i found that
> putting the assignment inside the try() allowed me to change my mind
> about having a catch() clause too with no other code changes inside
> the method.
>
> i have wrappers for common items that are closable, such as streams,
> readers/writers, cursors, etc, which check for null and swallow any
> exceptions, so it's only one line inside the finally().
>
> quite why stream.close() throws IOException is kinda beyond me though :-)
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Sqlite Error
Thank U for all...
On Tue, Feb 9, 2010 at 7:18 AM, Jason Proctor wrote:
> indeed -- i did investigate moving to this pattern, but i found that
> putting the assignment inside the try() allowed me to change my mind about
> having a catch() clause too with no other code changes inside the method.
>
> i have wrappers for common items that are closable, such as streams,
> readers/writers, cursors, etc, which check for null and swallow any
> exceptions, so it's only one line inside the finally().
>
> quite why stream.close() throws IOException is kinda beyond me though :-)
>
>
>
>
> Good advice -- always be on the lookout for cleanup that can be done
>> in a finally, even if you don't see it as strictly necessary!
>>
>> Actually, you can usually simplify this slightly:
>>
>> Cursor c = ...;
>> try {
>> dostuff(c); // Do something with the cursor
>> } finally {
>> c.close();
>> }
>>
>> There's no timing window or anything here. The variable 'c' won't be
>> assigned unless there's a successful return of a cursor, and there's
>> no opportunity for a throw between that and the operations on the
>> cursor.
>>
>> Separating the assignment and moving it into the try body does require
>> that you test for null in the finally clause. Occasionally it's worth
>> the extra hassle, so you can combine the finally with another try/
>> catch -- but usually it's better to simply use a separate try/catch
>> for each. In C++, assignments can generate exceptions, so doing the
>> assignment within the try is a good habit, and sometimes essential. In
>> Java, this is not a concern, so we can optimize for making it as easy
>> as possible to write and read the code, and thus encouraging liberal
>> use of the pattern!
>>
>> BTW, try/catch are not expensive in the non-throw case. It generates
>> static code ranges that are looked up during handling throw, and
>> doesn't involve any extra execution steps if no throw is done. So
>> always just try for the cleanest code.
>>
>> On Feb 8, 10:12 am, Jason Proctor
>> wrote:
>>
>>> well, like the error says, the cursor is being garbage collected but
>>> it hadn't been closed or deactivated.
>>>
>>> you must close your cursors!
>>>
>>> and do it in a finally block so that they still get closed even if
>>> other code throws an exception.
>>>
>>> for example --
>>>
>>> Cursor c = null;
>>>
>>> try
>>> {
>>>c = resolver.query (...);
>>>
>>>// ...run through the query}
>>>
>>> finally
>>> {
>>>if (c != null)
>>>{
>>> c.close ();
>>>}
>>>
>>> }
>>>
>>> not exactly like this, but you get the idea.
>>>
>>> hth
>>> J
>>>
>>>
>>>
>>>
>>>
>>> >Hi,
>>>
>>> >In my program i'm using sqlite database.
>>>
>>> >After using that Sqlite program when i'm using some other layout it
>>> >is showing the below exception.
>>>
>>> >02-06 14:17:59.320: INFO/dalvikvm(853): Uncaught exception thrown by
>>> >finalizer (will be discarded):
>>> >02-06 14:17:59.371: INFO/dalvikvm(853):
>>> >Ljava/lang/IllegalStateException;: Finalizing cursor
>>> >android.database.sqlite.sqlitecur...@43c4e358 on DB1 that has not
>>> >been deactivated or closed
>>> >02-06 14:17:59.729: INFO/dalvikvm(853): at
>>> >android.database.sqlite.SQLiteCursor.finalize(SQLiteCursor.java:596)
>>> >02-06 14:17:59.800: INFO/dalvikvm(853): at
>>> >dalvik.system.NativeStart.run(Native Method)
>>> >02-06 14:17:59.878: INFO/dalvikvm(853): Uncaught exception thrown by
>>> >finalizer (will be discarded):
>>> >02-06 14:17:59.900: INFO/dalvikvm(853):
>>> >Ljava/lang/IllegalStateException;: Finalizing cursor
>>> >android.database.sqlite.sqlitecur...@43b9cf30 on DB2 that has not
>>> >been deactivated or closed
>>> >02-06 14:17:59.909: INFO/dalvikvm(853): at
>>> >android.database.sqlite.SQLiteCursor.finalize(SQLiteCursor.java:596)
>>> >02-06 14:17:59.919: INFO/dalvikvm(853): at
>>> >dalvik.system.NativeStart.run(Native Method)
>>> >02-06 14:17:59.968: INFO/dalvikvm(853): Uncaught exception thrown by
>>> >finalizer (will be discarded):
>>> >02-06 14:17:59.989: INFO/dalvikvm(853):
>>> >Ljava/lang/IllegalStateException;: Finalizing cursor
>>> >android.database.sqlite.sqlitecur...@43b9c5e8 on null that has not
>>> >been deactivated or closed
>>> >02-06 14:18:00.049: INFO/dalvikvm(853): at
>>>
>> > >android.database.sqlite.SQLiteCursor.finalize(SQLiteCursor.java:596)
>>
>>> >02-06 14:18:00.049: INFO/dalvikvm(853): at
>>> >dalvik.system.NativeStart.run(Native Method)
>>> >02-06 14:18:00.088: INFO/dalvikvm(853): Uncaught exception thrown by
>>> >finalizer (will be discarded):
>>> >02-06 14:18:00.109: INFO/dalvikvm(853):
>>> >Ljava/lang/IllegalStateException;: Finalizing cursor
>>> >android.database.sqlite.sqlitecur...@43b95fc8 on null that has not
>>> >been deactivated or closed
>>> >02-06 14:18:00.119: INFO/dalvikvm(853): at
>>> >android.database.sqlite.SQLiteCursor.finalize(SQLiteCursor.java:596)
>>> >02-06 14:18:00.140: INFO/dalvikvm(853): at
>>> >da
[android-developers] Re: Sqlite Error
indeed -- i did investigate moving to this pattern, but i found that
putting the assignment inside the try() allowed me to change my mind
about having a catch() clause too with no other code changes inside
the method.
i have wrappers for common items that are closable, such as streams,
readers/writers, cursors, etc, which check for null and swallow any
exceptions, so it's only one line inside the finally().
quite why stream.close() throws IOException is kinda beyond me though :-)
Good advice -- always be on the lookout for cleanup that can be done
in a finally, even if you don't see it as strictly necessary!
Actually, you can usually simplify this slightly:
Cursor c = ...;
try {
dostuff(c); // Do something with the cursor
} finally {
c.close();
}
There's no timing window or anything here. The variable 'c' won't be
assigned unless there's a successful return of a cursor, and there's
no opportunity for a throw between that and the operations on the
cursor.
Separating the assignment and moving it into the try body does require
that you test for null in the finally clause. Occasionally it's worth
the extra hassle, so you can combine the finally with another try/
catch -- but usually it's better to simply use a separate try/catch
for each. In C++, assignments can generate exceptions, so doing the
assignment within the try is a good habit, and sometimes essential. In
Java, this is not a concern, so we can optimize for making it as easy
as possible to write and read the code, and thus encouraging liberal
use of the pattern!
BTW, try/catch are not expensive in the non-throw case. It generates
static code ranges that are looked up during handling throw, and
doesn't involve any extra execution steps if no throw is done. So
always just try for the cleanest code.
On Feb 8, 10:12 am, Jason Proctor
wrote:
well, like the error says, the cursor is being garbage collected but
it hadn't been closed or deactivated.
you must close your cursors!
and do it in a finally block so that they still get closed even if
other code throws an exception.
for example --
Cursor c = null;
try
{
c = resolver.query (...);
// ...run through the query}
finally
{
if (c != null)
{
c.close ();
}
}
not exactly like this, but you get the idea.
hth
J
>Hi,
>In my program i'm using sqlite database.
>After using that Sqlite program when i'm using some other layout it
>is showing the below exception.
>02-06 14:17:59.320: INFO/dalvikvm(853): Uncaught exception thrown by
>finalizer (will be discarded):
>02-06 14:17:59.371: INFO/dalvikvm(853):
>Ljava/lang/IllegalStateException;: Finalizing cursor
>android.database.sqlite.sqlitecur...@43c4e358 on DB1 that has not
>been deactivated or closed
>02-06 14:17:59.729: INFO/dalvikvm(853): at
>android.database.sqlite.SQLiteCursor.finalize(SQLiteCursor.java:596)
>02-06 14:17:59.800: INFO/dalvikvm(853): at
>dalvik.system.NativeStart.run(Native Method)
>02-06 14:17:59.878: INFO/dalvikvm(853): Uncaught exception thrown by
>finalizer (will be discarded):
>02-06 14:17:59.900: INFO/dalvikvm(853):
>Ljava/lang/IllegalStateException;: Finalizing cursor
>android.database.sqlite.sqlitecur...@43b9cf30 on DB2 that has not
>been deactivated or closed
>02-06 14:17:59.909: INFO/dalvikvm(853): at
>android.database.sqlite.SQLiteCursor.finalize(SQLiteCursor.java:596)
>02-06 14:17:59.919: INFO/dalvikvm(853): at
>dalvik.system.NativeStart.run(Native Method)
>02-06 14:17:59.968: INFO/dalvikvm(853): Uncaught exception thrown by
>finalizer (will be discarded):
>02-06 14:17:59.989: INFO/dalvikvm(853):
>Ljava/lang/IllegalStateException;: Finalizing cursor
>android.database.sqlite.sqlitecur...@43b9c5e8 on null that has not
>been deactivated or closed
>02-06 14:18:00.049: INFO/dalvikvm(853): at
> >android.database.sqlite.SQLiteCursor.finalize(SQLiteCursor.java:596)
>02-06 14:18:00.049: INFO/dalvikvm(853): at
>dalvik.system.NativeStart.run(Native Method)
>02-06 14:18:00.088: INFO/dalvikvm(853): Uncaught exception thrown by
>finalizer (will be discarded):
>02-06 14:18:00.109: INFO/dalvikvm(853):
>Ljava/lang/IllegalStateException;: Finalizing cursor
>android.database.sqlite.sqlitecur...@43b95fc8 on null that has not
>been deactivated or closed
>02-06 14:18:00.119: INFO/dalvikvm(853): at
>android.database.sqlite.SQLiteCursor.finalize(SQLiteCursor.java:596)
>02-06 14:18:00.140: INFO/dalvikvm(853): at
>dalvik.system.NativeStart.run(Native Method)
>wat's this?..
>how to over come this?
>any one can explain me?..
>--
>Thanks & Regards
>Sasikumar.S
>--
>You received this message because you are subscribed to the Google
>Groups "Android Developers" group.
>To post to this group, send email to android-developers@googlegroups.com
>To unsubscribe from this group, send email to
>android-developers+unsubscr...@googlegroups.com
>For more options, visit this group at
>
[android-developers] Re: Sqlite Error
Good advice -- always be on the lookout for cleanup that can be done
in a finally, even if you don't see it as strictly necessary!
Actually, you can usually simplify this slightly:
Cursor c = ...;
try {
dostuff(c); // Do something with the cursor
} finally {
c.close();
}
There's no timing window or anything here. The variable 'c' won't be
assigned unless there's a successful return of a cursor, and there's
no opportunity for a throw between that and the operations on the
cursor.
Separating the assignment and moving it into the try body does require
that you test for null in the finally clause. Occasionally it's worth
the extra hassle, so you can combine the finally with another try/
catch -- but usually it's better to simply use a separate try/catch
for each. In C++, assignments can generate exceptions, so doing the
assignment within the try is a good habit, and sometimes essential. In
Java, this is not a concern, so we can optimize for making it as easy
as possible to write and read the code, and thus encouraging liberal
use of the pattern!
BTW, try/catch are not expensive in the non-throw case. It generates
static code ranges that are looked up during handling throw, and
doesn't involve any extra execution steps if no throw is done. So
always just try for the cleanest code.
On Feb 8, 10:12 am, Jason Proctor
wrote:
> well, like the error says, the cursor is being garbage collected but
> it hadn't been closed or deactivated.
>
> you must close your cursors!
>
> and do it in a finally block so that they still get closed even if
> other code throws an exception.
>
> for example --
>
> Cursor c = null;
>
> try
> {
> c = resolver.query (...);
>
> // ...run through the query}
>
> finally
> {
> if (c != null)
> {
> c.close ();
> }
>
> }
>
> not exactly like this, but you get the idea.
>
> hth
> J
>
>
>
>
>
> >Hi,
>
> >In my program i'm using sqlite database.
>
> >After using that Sqlite program when i'm using some other layout it
> >is showing the below exception.
>
> >02-06 14:17:59.320: INFO/dalvikvm(853): Uncaught exception thrown by
> >finalizer (will be discarded):
> >02-06 14:17:59.371: INFO/dalvikvm(853):
> >Ljava/lang/IllegalStateException;: Finalizing cursor
> >android.database.sqlite.sqlitecur...@43c4e358 on DB1 that has not
> >been deactivated or closed
> >02-06 14:17:59.729: INFO/dalvikvm(853): at
> >android.database.sqlite.SQLiteCursor.finalize(SQLiteCursor.java:596)
> >02-06 14:17:59.800: INFO/dalvikvm(853): at
> >dalvik.system.NativeStart.run(Native Method)
> >02-06 14:17:59.878: INFO/dalvikvm(853): Uncaught exception thrown by
> >finalizer (will be discarded):
> >02-06 14:17:59.900: INFO/dalvikvm(853):
> >Ljava/lang/IllegalStateException;: Finalizing cursor
> >android.database.sqlite.sqlitecur...@43b9cf30 on DB2 that has not
> >been deactivated or closed
> >02-06 14:17:59.909: INFO/dalvikvm(853): at
> >android.database.sqlite.SQLiteCursor.finalize(SQLiteCursor.java:596)
> >02-06 14:17:59.919: INFO/dalvikvm(853): at
> >dalvik.system.NativeStart.run(Native Method)
> >02-06 14:17:59.968: INFO/dalvikvm(853): Uncaught exception thrown by
> >finalizer (will be discarded):
> >02-06 14:17:59.989: INFO/dalvikvm(853):
> >Ljava/lang/IllegalStateException;: Finalizing cursor
> >android.database.sqlite.sqlitecur...@43b9c5e8 on null that has not
> >been deactivated or closed
> >02-06 14:18:00.049: INFO/dalvikvm(853): at
> >android.database.sqlite.SQLiteCursor.finalize(SQLiteCursor.java:596)
> >02-06 14:18:00.049: INFO/dalvikvm(853): at
> >dalvik.system.NativeStart.run(Native Method)
> >02-06 14:18:00.088: INFO/dalvikvm(853): Uncaught exception thrown by
> >finalizer (will be discarded):
> >02-06 14:18:00.109: INFO/dalvikvm(853):
> >Ljava/lang/IllegalStateException;: Finalizing cursor
> >android.database.sqlite.sqlitecur...@43b95fc8 on null that has not
> >been deactivated or closed
> >02-06 14:18:00.119: INFO/dalvikvm(853): at
> >android.database.sqlite.SQLiteCursor.finalize(SQLiteCursor.java:596)
> >02-06 14:18:00.140: INFO/dalvikvm(853): at
> >dalvik.system.NativeStart.run(Native Method)
>
> >wat's this?..
> >how to over come this?
> >any one can explain me?..
>
> >--
> >Thanks & Regards
> >Sasikumar.S
>
> >--
> >You received this message because you are subscribed to the Google
> >Groups "Android Developers" group.
> >To post to this group, send email to android-developers@googlegroups.com
> >To unsubscribe from this group, send email to
> >android-developers+unsubscr...@googlegroups.com
> >For more options, visit this group at
> >http://groups.google.com/group/android-developers?hl=en
>
> --
> jason.vp.engineering.particle
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroup
Re: [android-developers] Re: Sqlite Error
Thank U Manoj. I will try it and then i will inform u. On Sat, Feb 6, 2010 at 2:33 PM, Manoj wrote: > Possible reason for this could be the cursor going out of limits. > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- Thanks & Regards Sasikumar.S -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Sqlite Error
Possible reason for this could be the cursor going out of limits. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: SQlite error
go through the Notepad tutorial @ http://developer.android.com/guide/tutorials/notepad/index.html and Notepad sample code @ http://developer.android.com/guide/samples/NotePad/index.html On May 5, 4:00 pm, N V wrote: > Hi to all... > > I am creating a simple application of database... I am first > time using it.. I tried sample > program, But it has lot of errors... Can any one tell me how can write > simple INSERT DELETE > UPDATE quries...?ans also Is there any settings for the database in > eclipse...? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
