Forum PHP.pl

powiedz lepiej co chcesz zrobić bo to co jest wyżej jest imho bez sensu...

Normanos:

Kolega rzuca wyjątkiem w modelu (chociaż nie w przykładzie ). 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.

Zapewne wiesz jak wywoływać strony błędów w Kohanie (ja nie ) 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

Ten post edytował LBO 20.08.2008, 16:58:54

LBO: ja widzę czym kolega rzuca w przykładzie tylko nie widzę CELOWOŚCI tego działania (w tym konkretnym przypadku, nie żebym tu wyjątki negował ).

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).

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:

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

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

o najprostszy przykład

Ten post edytował LBO 20.08.2008, 17:39:15

tak uważam a nie mogę?

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.

Chyba Tobie zaciemni
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.

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. (jak i do sterowania przebiegiem). a w reszcie sie zgadzam.

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

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.

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ą

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

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.

@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.

Ten post edytował LBO 21.08.2008, 12:03:45

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.
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ć.

@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 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