> recover, if anything?
No, let the system Force Close the app, roll back by existing SQL
transaction and let the user submit a bug report via the Error
Reporting.
> Actually, this is a pretty good specific case to talk about.
>
> Are you loading JSON from or saving it to a file?
No, I am using JSON for state saving complex objects. Not sure how
the system implements that, it may save it to a file, I don't know, I
don't care.
> I'm curious what
> would happen in the case that a write of a file in mid-stream failed.
I hope an IOException would be thrown as one would hope the file
system would catch that.
> IOException, remove the file, and notify the user?
No, why would I do that? What the f*ck could the user do about it?
That's the whole point of this discussion. The user cannot do
anything about the vast majoriy of these checked expections, so there
is point of trying to recover from them gracefully?
> I'm curious to know what was in the 95% that you got rid of and what
> you did to deal with what were previously checked exceptions?
I used to just propogate these checked execptions all the way to the
point where I could no longer, at which poiint I displayed a pop-up
window with the exception. I am no longer doing that and just the let
the system terminate the app.
--
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
No comments:
Post a Comment