Yeah, that's what I mean by checked exeptions. But my app only throws checked exceptions if there really is an error state, so I don't particularly care what happens afterwards -- the app is hosed already.
I need to either: a) provide a way for the user to e-mail me the error so I can fix it b) throw an unchecked exeption (with my checked exception as the cause) and hope the user will have a chance to send it via the normal Android error reporting channel. How do you guys deal with checked exceptions in your app? On Jul 26, 9:19 am, Doug <[email protected]> wrote: > On Jul 25, 6:49 am, Zsolt Vasvari <[email protected]> wrote: > > > Actually, I just realized how this can happen. If I get a checked > > exception in onCreate(), I just display it in a pop-up, which the user > > can dismiss and then press the back button and get the NPE. Now how a > > checked exception can happen is another very good question, but I > > don't expect help with that..... > > A checked exception is one that must be caught from the perspective of > the java compiler (extends Exception). An unchecked exception doesn't > have to be caught (extends RuntimeException). The java compiler will > tell you if a checked exception can be thrown and oblige you to handle > it. Is this what you're talking about? > > If you show a dialog in in onCreate, I'm pretty sure the activity > lifecycle is still going to complete. I don't think you can prevent > that. If you don't want the user to interact with the activity at all > after you show a dialog, I'd recommend putting a call to finish() in > the dismiss and cancel handlers for your dialog so that the activity > will be on its way out ASAP. > > Doug -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
