Wyjątki dla błędnych URLi - dobra metoda? Opcje

[pitbull82]

Witam

Powszechnie mówi się, że wyjątki powinno stosować się do obsługi nieprzewidzianych sytuacji. Czy Waszym zdaniem powinno się je zastosować do obsługi błędnych URLi?

Mam taką sytuację, że u mnie błędne URLe są/będą wykrywane na różnym poziomie:

1. router - analizuje składnię urla i jeśli nie w stanie znaleźć w nim pożądanych elementów, jeśli znajdzie jakieś duplikaty parametrów lub kolejność parametrów jest nieprawidłowa ustawia url przekierowania i rzuca wyjątek
2. dispatcher - sprawdza czy na podstawie danych z routera jest w stanie wywołać odpowiedni kontroler i akcję - jeśli nie ustawia url przekierowania i rzuca wyjątek
3. konkretny kontroler sprawdza czy nie ma nadmiarowych parametrów/czy ma wszystkie wymagane parametry/czy parametry mają poprawne wartości - jeśli nie ustawia url przekierowania i rzuca wyjątek

Wszystkie wyjątki łapie frontcontroller i uruchamia przekierowanie. Teoretycznie można by to zrealizować bez wyjątków, ale wydaje mi się że tak jest przejrzyściej. Pytanie tylko czy to trochę nie nadużycie wyjątków, bo przecież w każdym z 3 poziomów jestem w stanie stwierdzić że URL jest niepoprawny i po prostu uruchomić przekierowanie zamiast rzucać wyjątek i nakładać to zadanie na front controllera. Jak uważacie?

Pozdrawiam

[thek]

Myślę, że najbezpieczniej jest mimo wszystko puścić "pokręcony" url z adnotacja w stronie o canonical. Dzieki temu mimo iż strona zostanie złapana w sieć, to nie sprawi problemu z duplikatem, gdyż wskaże prawidłowy url robotowi. Dzięki temu nie będziesz zmuszony modyfikować kolejności parametrów, ale podasz je w prawidłowej i uniknesz redirecta niepotrzebnego. Jaki będzie efekt po kolei?
Router - usunie duble parametrów, ustawi kontroler, metodę i parametry,
Dispatcher - przekaże do kontrolera i jego metody żądanie z parametrami lub wywali, że takiego kontrolera brak (wyjątek)
Kontroler - wywoła metodę z odpowiednimi parametrami rozpoznanymi. Sygnalizuje błędne parametry, metody czy brak wymaganych parametrów. Przy wrzucaniu znanych sobie parametrów sprawdza zgodność kolejności parametrów i ewentualnie ustawia canonical.

Zauważ jak prostą logiką pozbyłem się niepotrzebnie 301 nadmiarowych i uodporniłem na duplicate content za jednym zamachem. 301 na prawidłowy adres to bowiem nie jedyne rozwiązanie. Stosuj je jedynie gdy faktycznie tak musi być i koniec. Sprawiasz bowiem, że masz więcej żądań niepotrzebnie. 301 powinno być stosowane gdy masz brak danych koniecznych w danym elemencie. Przykładem jest choćby to co robiłem niedawno podczas przepinania ze starej na nową wersję serwisu. W starej wersji w linku był id i kompletnie inna forma SEO niż na nowym. Wymuszało to na mnie dorwanie się do bazy by na podstawie ID pobrać wymagane dla nowego SEO-linku dane. Tego ani router, ani dispatcher nie wykonują, więc musiałem iść aż do kontrolera, który to zrobił i wywołał właściwe 301 ostatecznie. Ale to są jedne z nielicznych przypadków gdzie tak powinno się robić.