Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [kohana] problem z wyjatkami
Forum PHP.pl > Forum > PHP > Frameworki
terabit
Mam problem z działaniem wyjątków w Kohanie...

przykladowy model:
  1. <?php
  2. public function robTo($id) {
  3.  
  4. $x = 1;
  5. if ($x > 1) {
  6. throw new Kohana_User_Exception('adf', 'asdf', 'kohana_error_page');
  7. }
  8.  
  9. }
  10. ?>


no i teraz w kontrolerze
  1. <?php
  2. public function cosTam($id) {
  3.  
  4. try {
  5.  
  6. $model = new nazwa...;
  7. $model -> robTo($id);
  8.  
  9. } catch (Kohana_User_Exception $e) {
  10.  
  11. echo $e -> getMessage();
  12.  
  13. }
  14.  
  15. }
  16. ?>


problem w tym ze nie wiem jak wyrzucić tekst na osobną stronę...
czyli do kohana_error_page...

no i w ogóle czy dobrze tego używam... i czy w modelu powinno być wyrzucenie wyjątku... hmmm
nrm
powiedz lepiej co chcesz zrobić bo to co jest wyżej jest imho bez sensu...
terabit
hmmm

np. w modelu usuwam dane z bazy, jesli coś będzie nie tak to wiadomo... wyjątek winksmiley.jpg
LBO
Normanos:

Kolega rzuca wyjątkiem w modelu (chociaż nie w przykładzie biggrin.gif). Przechwytuje go w akcji i teraz się pyta jak tekst wyjątku przekazać gdzieś tam...


...i się tutaj wtrącę - Treść wiadomości rzucanych wyjątków NIE JEST przeznaczona dla użytkownika. Służy ona tylko i wyłącznie programiście. Przechwytując wyjątek i tak powinieneś wiedzieć dlaczego jest rzucany, czy to przez to, że rzucasz go tylko w określonym momencie, czy przez typ wyjątku. Użytkownikowi powinieneś sprezentować tylko zgrabny ekranik, że coś jest nie tak/nie udało się wykonać operacji/coś tam nie istnieje.
terabit
no więc co mam zrobić? :]
LBO
Zapewne wiesz jak wywoływać strony błędów w Kohanie (ja nie biggrin.gif) Zrób sobie kilka typów takich stron w zależności od rodzaju i je wywołuj... w szczegółach pomoże Tobie @normanos na pewno
nrm
LBO: ja widzę czym kolega rzuca w przykładzie tylko nie widzę CELOWOŚCI tego działania winksmiley.jpg (w tym konkretnym przypadku, nie żebym tu wyjątki negował winksmiley.jpg ).

terabit: kohana ciebie poinformuje sama o każdym wyjątku, a jak chodzi o info dla usera no najprościej zwracać booleana z modelu i wtedy z kontrolera wykonać dana akcję (np. 404, komunikat w flash sesji).
LBO
normanos, uważasz, że nie powinno się rzucać wyjątków w modelu?

Sorry, uważam, że nie powinno się polegać tylko na zwracanych wartościach, po to są stworzone wyjątki, żeby to było zbędne.

edit:
Cytat(normanos @ 20.08.2008, 18:23:05 ) *
terabit: kohana ciebie poinformuje sama o każdym wyjątku, a jak chodzi o info dla usera no najprościej zwracać booleana z modelu i wtedy z kontrolera wykonać dana akcję (np. 404, komunikat w flash sesji).

To nie jest najlepszy sposób moim zdaniem. A co jeżeli model ma zwracać jakieś inne dane, albo boolean w innym celu?

  1. <?php
  2. public function executeRead() { // wywołujemy akcję
  3. try {
  4. $userModel = $this->context->getModel('User'); // bierzemy model...
  5. $user = $usersModel->getById($rd->getParameter('id')); // ...i pobieramy dane użytkownika
  6. if ($user) { // użytkownik istnieje
  7. $this->setAttribute('user', $user); // ustawiamy zmienną dla widoku
  8. return 'Success'; // zwracamy nazwę widoku, który wypisze dane użytkownika
  9. }
  10. // użytkownik nie znaleziony, bo model zwrócił FALSE (może też być null)
  11. return 'Error'; // widok błędu, nie znaleziono użytkownika, może być 404 też
  12. } catch (Exception $e) {
  13. return 'FatalError'; // "Przepraszamy, ale wystąpił błąd krytyczny - proszę spróbować jeszcze raz"
  14. }
  15. }
  16. ?>


o najprostszy przykład
nrm
tak uważam winksmiley.jpg a nie mogę? winksmiley.jpg

takie stosowanie jak na przykładzie powyżej tylko zaciemnia kod aplikacji, robi burdel, a nie przynosi nic sensownego. Przecież on tak na prawdę nie potrzebuje wyjątku do niczego sensownego tylko dac info na ekran dla usera. do tego od sterowania przebiegiem mam kontroler i on zdecyduje co dalej, model ma zwrocic dane lub false. dla mnie jest tak sensowniej, logiczniej i wygodniej.
LBO
Chyba Tobie zaciemni smile.gif
Burdel to może zrobić 10 rodzajów wyjątków sprawdzanych w jednym miejscu i zagnieżdżone.
A tak mam strefę gdzie wszystko idzie jak po maśle i tam sobie sprawdzam, co zwrócił model a w catchu zabezpieczenie na wypadek błędu który się może zdążyć zawsze prawda? Można to ewentualnie złapać w jakimś filtrze, ale to nie o to chodzi.
Wyjątki mają zabezpieczać aplikację i przebieg o którym wspomniałeś.
Nie twierdzę, że trzeba rzucać wyjątkiem za każdym razem, ale są one przydatna częścią PHP i należy z Nich korzystać. Szczególnie, że modelu możesz używać nie swoich bibliotek.
nrm
ja, i to drugi raz pisze, nie neguje sensu wyjatkow. tylko stosowanie ich jak w przykladzie wyzej w kazdej metodzie modelu jest dla mnie bez sensu. winksmiley.jpg (jak i do sterowania przebiegiem). a w reszcie sie zgadzam.
LBO
Napisałem przecież że możesz nie używać własnych bibliotek, prawda? A te z racji swojej natury nie muszą kierować się Twoją filozofią (no chyba, że chcesz łapać te wyjątki w każdej metodzie modelu, żeby broń Boże nie przeszły do kontrolera).
W przykładzie który podałem, kontroler wybiera też widoki (w tym 404) na podstawie zwróconych danych. Jeżeli nie chcesz łapać tych wyjątków w akcji, też napisałem, że można to jakimś filtrze zrobić (zakładam, że Kohana posiada filtry w swojej architekturze).

No , ale chyba za bardzo odeszliśmy od tematu, należy się nam po pomógł +1 smile.gif
terabit
czy to będzie poprawnie:
- w modelu wyrzucam wyjątek z jakimś tam błędem (throw new Exception ('asdf')winksmiley.jpg
- w kontrolerze w razie błędu go przechwytuje
- przechwycony wyjątek wrzucam do widoku np Error.php ?
:]

czy mam w modelu zwrócić albo true (lub jakas tresc czy cos..) albo false i w kontrolerze to sprawdzić i dopiero według tego wyświetlić wyjątek?
tak jak to jest w dokumentacji przedstawione - http://docs.kohanaphp.com/general/errorhandling - chociaż to rozwiązanie mi się za bardzo nie podoba...
LBO
To jest dosyć delikatna sprawa i trzeba podejść z umiarem. Musisz rozróżnić rodzaj błędu. Błędem będzie kiedy nie znajdziesz artykułu po id (bo model zwrócił false albo null), ale błędem będzie też kiedy np. w Propelu lub Doctrine - które możesz użyć w modelu - rzucą wyjątkiem. Musisz potrafić obsłużyć te przypadki.
nrm
Mam nadzieję, że autor tematu zrozumiał zastosowanie tego w Kohanie - a jak nie to proponuje porzucać sobie wyjątkami, a potem przejść na wersje produkcyjną winksmiley.jpg
destroyerr
normanos możesz wytłumaczyć jaka będzie różnica między wersją developerską a produkcyjną?
Moim zdaniem nie powinno być żadnej różnicy, w obu wersjach wyjątek powinien być chwycony tak samo i tak samo obsłużony.
Jeśli się mylę przepraszam i proszę o poprawienie winksmiley.jpg
mike
Cytat(destroyerr @ 21.08.2008, 11:58:04 ) *
Moim zdaniem nie powinno być żadnej różnicy, w obu wersjach wyjątek powinien być chwycony tak samo i tak samo obsłużony.
Jeśli się mylę przepraszam i proszę o poprawienie winksmiley.jpg
Mylisz się.
W wersji deweloperskiej wyjątek może powodować wyświetlenie strony debug ze szczegółowymi informacjami o błędzie, aktualną konfiguracją i parametrami jakie zawierało żądanie. Ponadto fajnie zobaczyć trace wyjątku.
To samo dla usera? Nie. On niech zobaczy stronę 500.

Tak jest zresztą w symfony.
LBO
@mike, czyli obsługujemy wyjątki, czy w samej akcji, czy w jakimś filtrze. I poniekąd są obsługiwane tak samo, zmienia się widok.

Z reszta to też zależy od frameworka. Używałeś chyba Agavi, prawda? Tam sobie zwracasz widok 404 w Symfony natomiast rzucasz wyjątkiem 404.
mike
Cytat(LBO @ 21.08.2008, 13:01:34 ) *
@mike, czyli obsługujemy wyjątki, czy w samej akcji, czy w jakimś filtrze.
W akcji na pewno nie. Wyjątek powinien obsłużyć jaakiś filtr lub kontroler. Jeśli model użyty w akcji rzucił wyjątek to akcja może go obsłużyć (bo może to jakiś pikuś) albo puścić dalej. Na pewno akcja powinna mieć możliwość złapania takiego wyjątku.
Cytat(LBO @ 21.08.2008, 13:01:34 ) *
I poniekąd są obsługiwane tak samo, zmienia się widok.
Niekoniecznie. Bez sensu na przykład żeby wyjątek zgłoszony w trybie deweloperskim wysyłał mi maila lub nawet zapisywał się do logów jeśli nie chcę.
Poza widokiem sposób obsługi również może się różnić.
nrm
@destroyerr: jest tak jak napisał Mike. Jeżeli ty chcesz wyjątkami sterować przebiegiem, tudzież wyświetlać userowi "sorry nie ma wyników" to nic z tego nie wyjdzie bo w produkcyjnej upraszczając user zobaczy jakieś 404 a wyjątki zostaną "wyciszone".

Jak pisałem wcześniej - zastosowanie wyjątków jest dla programisty i samej aplikacji, dla debuga itd. komunikacje z userem trzeba robić w inny sposób (jak pisałem wyżej, dla mnie sposób LBO nie ma w ogóle rąk i nóg ale kazdy orze jak może winksmiley.jpg i ma swoje sposoby. Ja się odnosze do tego przypadku, tego fw.

od razu przy okazji tematu dodam dla potomnosci - nie zostawiajcie wersji dev kohany na produkcyjnych maszynach. w np. wywaleniu mysqla w debugu widać pełne dane, w tym hasło winksmiley.jpg
terabit
juz sie troche pogubilem....


a więc jak np wyświetlic userowi ze nie ma wynikow?

hmmm... zliczac ilosc rekordow? i wedlug tego wyswietlic komunikat?

i w końcu do czego używać wyjątków?
Po co będą mi potrzebne?
Gdy wystąpi jakiś błąd mam sobie go zapisywac w logach?


Ja po prostu chce pisać poprawnie ! winksmiley.jpg
nrm
chocby tak jak napisałem wcześniej:

w uproszczeniu


  1. <?php
  2. model:
  3. $sql = blabla
  4. if($sql->count() > 0)
  5. return $sql->result();
  6. else
  7. return false;
  8.  
  9. kontroler:
  10. if(!tozmodelu)
  11. $this->session->set_flash('komunikat', 'sorry koles, nie ma wynikow');
  12. url::redirect('costam');
  13. ?>


można też dać 404, można bezpośrednio w widoku metody - to wszystko zalezy od kontekstu danej akcji.

po co ci wyjatki? do debuga wersji developerskiej, do logowania bledow wersji produkcyjnej etc. sa bardzo pozyteczne.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.