2010-09-27 20 views
9

Jestem nowy w rozwoju aplikacji mobilnych na Androida. Chciałbym wiedzieć, w jaki sposób można obsługiwać wyjątków, takich jak wyjątki związane z HttpConnection lub innych wyjątków? Czy muszę wyświetlać użytkownikowi AlertDialog?Przykładowy kod do obsługi wyjątków

Prosimy o podanie przykładowego kodu lub kodu źródłowego projektu, w jaki sposób mogę obsłużyć HttpConnection lub podobny typ wyjątków.

Odpowiedz

10

Sposób obsługi wyjątku zależy od wyjątku. Jeśli wyjątek jest coś, czego nie można odzyskać, a użytkownik musi wiedzieć, o czym można złapać wyjątek i pokazać go w AlertDialog:

try { 
    // do something 
} catch (SomeImportantException e) { 
    AlertDialog.Builder builder = new AlertDialog.Builder(this); 
    builder.setMessage("User friendly text explaining what went wrong."); 
    AlertDialog alert = builder.create(); 
    alert.show(); 
} 

Aby uzyskać więcej informacji na temat okna dialogowego, patrz creating dialogs.

Alternatywnie, jeśli wyjątek jest czymś, z czym możesz sobie poradzić, możesz po prostu zarejestrować informacje o wyjątku i przejść dalej.

try { 
    // do something 
} catch (SomeLessImportantException e) { 
    Log.d(tag, "Failed to do something: " + e.getMessage()); 
} 
+0

Chociaż ta odpowiedź jest dokładna, poniższa odpowiedź Paiego jest znacznie bardziej pomocna. – Gowiem

17

Istnieją 2 różne rodzaje wyjątków w Javie: zaznaczone i niezaznaczone. Istnieje wielka debata, nad którą lepiej się posługiwać, oba argumenty są dobre.

Zasadniczo wyjątek sprawdzany wywodzi się z java.lang.Exception i wymaga, aby w przypadku, gdy nie określisz swojej metody jako "throws MyCheckedException", musisz przechwycić wyjątek w ramach metody i obsłużyć go.

// throw the exception 

void foo() throws MyCheckedException 
{ 
    throw new MyCheckedException(); 
} 

// or handle the exception 

void foo() 
{ 
    try { 
     throw new MyCheckedException(); 
    } catch (MyRuntimeException e) { 
     e.printStackTrace(); 
    } 
} 

Niesprawdzony wyjątek, pochodzące z java.lang.RuntimeException wymaga ani że określenie „rzuca” w definicji metody ani że go obsłużyć.

void foo() 
{ 
    throw new MyUncheckedException(); 
} 

Zaletą sprawdzanego jest to, że kompilator wyświetli ostrzeżenie, gdy użytkownik nie zajmie się wyjątkiem.

Wadą jest to, że musisz zadeklarować blok try/catch lub throws dla każdego sprawdzanego wyjątku, a kod wyższego poziomu może być dość kłopotliwy, próbując obsłużyć wszystkie typy wyjątków.

Z tego powodu, jeśli jesteś ostrożny, możesz użyć opcji Niezaznaczone wyjątki.

BTW, możesz wybrać typ wyjątku tylko wtedy, gdy zdefiniujesz własny.

Po napotkaniu Wyjątków z Java lub biblioteki innej firmy, musisz zdecydować, jak sobie z tym poradzić. na przykład Jeśli metoda trzeciej strony zgłasza metodę CheckedException1, musisz albo ją obsłużyć, albo zadeklarować metodę wywołania jako "throws CheckedException1". Jeśli chcesz uniknąć używania Wyjątków zaznaczonych, możesz go opakować w Niezaznaczony wyjątek i wyrzucić.

void foo() // no throws declaration 
{ 
    try { 
     thirdPartyObj.thirdPartyMethod(); // this throws CheckedException1 
    } 
    catch (CheckedException1 e) { 
     throw new MyUncheckedException(e); // this will wrap the checked in an unchecked. 
    } 
} 

Pamiętaj, że możesz rzucić wyjątek Niezaznaczony bez deklaracji "rzutów". Aby uzyskać dostęp do oryginalnego obiektu CheckedException1 z wyższej kategorii, można użyć metody .getCause() wyjątku Unchecked.

void caller() 
{ 
    try { 
     foo(); 
    } catch (MyUncheckedException e) { 
     CheckedException1 ce1 = e.getCause(); 
     ce1.printStackTrace(); 
    } 
} 

... ale dlatego, że wyjątek od foo() nie jest zaznaczona, nie mieć poradzić albo zadeklarować „wyrzuca”.

Odnośnie logowania, istnieją różne szkoły myślenia na ten temat.

  1. Zaloguj go, gdy wyjątek występuje (niski - poziom)
  2. Zaloguj się, gdy osiągnie górną (wysoki - poziom)
  3. Zaloguj się jeśli masz wystarczająco dużo informacji, aby odpowiednie działanie i/lub wiadomość dziennika. (średni poziom)

Dobrą polityką, którą znalazłem, jest zainstalowanie niezamkniętego sterownika wyjątków, który zajmie się wszystkimi nieprzypadkowymi (oczywiście niezaznaczonymi) wyjątkami. W ten sposób wszystko, co zostanie pominięte, będzie rejestrowane i potencjalnie obsługiwane przed awarią systemu.

public class MyExceptionHandler implements UncaughtExceptionHandler 
{  
    @Override 
    public void uncaughtException(Thread thread, Throwable ex) 
    { 
     ex.printStackTrace(); 
    } 
} 

// In your high-level code 
Thread.setDefaultUncaughtExceptionHandler(new MyExceptionHandler()); 

i wszystkie wyjątki, które mogą być obsługiwane z wdziękiem, złapać i obsługiwać je w module gdzie wiesz wystarczająco dużo o sytuacji ewentualnie skorygować problem i spróbuj ponownie.

+1

To jest ** z łatwością ** najlepsze wyjaśnienie, które przeczytałem na temat obsługi wyjątków, co jest smutne, ponieważ przeglądałem je przez godzinę lub dwie. Zasługujesz na wiele innych upiorów, proszę pana. – Gowiem

+0

Najlepsze dla ciebie, Gowie47! :) – paiego

+1

Dziękuję za dobry przykład, jak radzić sobie z wyjątkami stron trzecich. – shadowhorst

0

Możesz użyć wtyczki ACRA, która oferuje tę funkcję lub BugSense, aby zbierać raporty o błędach. Nota prawna: Jestem założycielem w BugSense.

Powiązane problemy