2012-07-18 10 views
6

dominującej:Mam klasy nadrzędnej z @ExceptionHandler i podklasy z jego własną wersją. Dostaję niejednoznaczne error metoda

@ExceptionHandler(NoUserException.class) 
protected ModelAndView handleException(NoUserException e) { 
    Map<String, Object> model = new HashMap<String, Object>(); 

    model.put(ModelKeys.HOST_KEY, "message"); 

    return new ModelAndView("noAccess",model); 
} 

Dziecko:

@ExceptionHandler(NoUserException.class) 
protected void handleException(NoUserException e, HttpServletRequest request, HttpServletResponse response) throws IOException { 
    logger.error("Invalid user."); 
    respond(CLIENT_USER_ERROR,response); 
} 

Tak, trzeba je mieć różne parametry i wyjść.

+0

co masz na myśli? To jest jakiś kod w klasie nadrzędnej ... to tylko prosty rzut nowego NoUserException() –

+0

to nie jest? To się dzieje, kiedy go prowadzę. nie można zdecydować, którą metodę zastosować. –

+0

Prawdopodobnie dlatego, że istnieją dwa zdefiniowane '@ ExceptionHandler', jeden odziedziczony po nadklasie i nowy zdefiniowany w podklasie. Nie wiem, jak to zmienić, nie stanie się to automatycznie, ponieważ metody nie mają tego samego podpisu. – purtip31

Odpowiedz

8

Nie można mieć dwóch metod z tą samą obsługą wyjątku, przepraszam, to po prostu nie jest obsługiwane. Kod, który je rozwiązuje, nie rozróżnia między nadrzędnymi podklasami i uważa podklasę za "bardziej szczegółową". Kod jest w org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerExceptionResolver, jeśli jesteś zainteresowany. Nie byłoby trudno stworzyć własną implementację AbstractHandlerExceptionResolver opartą na tej, która uwzględnia metodę bezpośrednio na kontrolerze, bardziej konkretny wynik niż dziedziczoną metodę.

edytuj: komentarz osobisty, Znalazłem z biegiem czasu, że lepiej jest powstrzymać chęć użycia "dziedziczenia jako narzędzia do szablonów" podczas tworzenia kontrolerów z kontrolkami Spring MVC. Kod widoku jest z natury nietrwały i proceduralny, dlatego najpierw tworzymy osobną "warstwę widoku". Zbytnie podejście do DRY i "ponownego użycia" nie przynosi ci korzyści. Jeśli to narusza zasadę Liskov Substitution, nie robię tego. YMMV oczywiście.

1

Dlaczego po prostu nie delegować wdrożenia handleException() na inną metodę?

// superclass 
protected ModelAndView handleExceptionImpl(
     NoUserException e, 
     HttpServletResponse response) { 
    Map<String, Object> model = new HashMap<String, Object>(); 
    model.put(ModelKeys.HOST_KEY, "message"); 
    return new ModelAndView("noAccess",model); 
} 

@ExceptionHandler(NoUserException.class) 
protected ModelAndView handleException(
     NoUserException e, 
     HttpServletResponse response) { 
    return handleExceptionImpl(e, response); 
} 

// subclass 
@Override 
protected ModelAndView handleExceptionImpl(
     NoUserException e, 
     HttpServletResponse response) { 
    logger.error("Invalid user."); 
    respond(CLIENT_USER_ERROR,response); 
} 
Powiązane problemy