Hi Lew, I agree with you and because that I'm spending a lot of time looking for the best solution to handler my exceptions in my android application. If you didn't understand this way, sorry.
We have dozen of different technics to handle exceptions in a java application, AOP is just one them http://janistoolbox.typepad.com/blog/2009/12/errorhandlingaop.html The point is not if exceptions are important or not, particularly for me are very important for a success in a application (but it doesn't matter). So, this is my first android application and I just would like to heard and share some knowledge about usually how the guys handle your exceptions. Just that. ACRA is an awesome report bug solution to handle uncaught exceptions (100% free). Cheers, Luiz On Wed, Nov 21, 2012 at 3:30 PM, Lew <[email protected]> wrote: > Luiz Henrique wrote: > >> we are sharing the same ideas about how and in what kind of condition >> should be showed error messages. Btw, I'm using ACRA to handle uncaught >> exception and it have worked fine. >> > > "ACRA"? > > >> >> About catch-exception you understand me well. So, nowadays I'm using >> try/catch to grab the exceptions and sometimes there is a bunch of "dirty" >> code just to handle exceptions. I would like to know is there is some >> approach in android [sic] to handle in an unique Class/Method >> catch-exceptions. For example, something we can do using interceptors/AOP >> for others applications? >> > > Why would you call that code "dirty"? > > Is code that handles bad conditions somehow inferior to code that handles > the happy path? > I'm inclined to think the exact opposite. > > Much more likely to be good engineering than "interceptors/AOP" (huh?) > would be good refactoring > of your code. Dealing with exceptions is not an Android issue but a > programming issue, and you > need to fully understand what exceptions are and how they fit > strategically. > > The boilerplate for exceptions can be verbose, but hey, at least you don't > actually have to work > for a living. The worst you can fear from it is a slight increase in > callous on your fingertips. > > You reduce verbosity by isolating checked-exception handling to the > lower-level routines. One > standard (not necessarily best-practice) technique is to rethrow as a > custom exception (checked > or unchecked) which is handled by the top controller level in a > user-friendly way. The lower-level > routines do something pretty specific, say, open a resource, and eat all > the checked exceptions > that might engender, replacing them with defaults, custom exceptions or > navigation, error return > values, or whatever your strategy dictates. > > By relegating verbose exception handling to lower-level routines, the > higher-level ones read > much more like happy-path laconic self-documenting scripts. > > What do you mean by "others applications"? > > -- > Lew > > -- > 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 > -- 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
