Kusterek napisał
@up
własnie ten dekorator mi sie obił o uszy :P
Co do zamiany Colorw na strukture MyColor z polem RGB typu INT to potem zczytywać to np tak:
Kod:
Color c = Color.FromArgb(mb.RGB);
No i kolejne pytanko jak dobrze uzywac?
Kod:
throw new NotImplementedException ();
mam sobie metode:
Kod:
public IList<Note> Sort()
{
throw new NotImplementedException ();
}
i chce ja sobie wykonac
Kod:
public static IList<Note> Sort()
{
try{
return NoteRepositoryADO.Sort ();
}
catch(NotImplementedException notImp)
{
Console.WriteLine (notImp.Message);
}
}
tylko ze to mi sie nie wykona bez returna po za try{}, cos chyba zle robie nie?
@
Kusterek ;
Wyjątka używasz jak każdego innego.
Czyli:
1) W danym kodzie, gdy wykonujesz metodę, o której wiesz, że jej interfejs może wyrzucić dany wyjątek, a wiesz jak go obsłużyć, tworzysz block try - catch
2) Jeśli nie wiesz jak obsłużyć wyjątku, to najprawdopodobniej nie jest to Twoja odpowiedzialność i pozwalasz wyjątkowi iść wyżej gdzieś, gdzie ktoś będzie wiedział jak to zrobić.
Przykład ( trochę z dupy ale musiałem wymyśleć jakiś prosty scenariusz ) xD
Wyobraź sobie że masz klasę , która jest reprezentacją przyjęcia ( no takiego urodzinowego np xD ), no i generalnie implementacja tego ,,przyjęcia" zakłada, że na tym przyjęciu będzie ,,ktoś śmieszny" który będzie rozbawiał publikę :P
Kod:
class Party {
private Funny funnyGuy;
public Party(Funny funnyGuy) {
this.funnyGuy = funnyGuy;
}
public void makeParty() {
this.funnyGuy.doFunnyThings();
}
}
Teraz masz interfejs Funny i dwie przykładowe implementacje ( w tym jedna wyrzuca wyjątek bo nie jest gotowa ) :
Kod:
interface Funny {
void doFunnyThings();
}
class FunnyMcDonaldClown : Funny {
public void doFunnyThings() {
Console.WriteLine("I'm the McDonald guy and I'm doing a lot of funny things!");
}
}
class FunnyComedian : Funny {
public void doFunnyThings() {
throw new NotImplementedException();
}
}
Teraz musisz zastanowić się nad tym, czy nasza klasa Party powinna potrafić obsłużyć wyjątek ,,NotImplementedException" ? Konkretniej, pytanie brzmi - czy Nasza klasa przyjęcia powinna umieć poradzić sobie z sytuacją , kiedy dany ,,rozśmieszacz" nie będzie zaimplementowany?
Moim zdaniem np nie - użycie kodu który nie jest zaimplementowany to moim zdaniem błąd i taki dependency nie powinien być nigdy wstrzyknięty. Dlatego, jeśli wyjątek zostanie wyrzucony, zostawiam go, aby poleciał dalej.
Ale jeśli, np zdefiniowalibyśmy wyjątek w stylu:
Kod:
class NotFunnyException : Exception { }
I zadalibyśmy to pytanie ponownie, brzmiałoby ono: ,,Czy nasza klasa przyjęcia powinna umieć obsłużyć sytuację, w której rozśmieszacz nie jest śmieszny?" - i tu odpowiedź brzmi tak.
Więc kod wyżej w klasie Party można zmodyfikować na:
Kod:
public void makeParty() {
try {
this.funnyGuy.doFunnyThings();
} catch(NotFunnyException) {
this.funnyGuy.kickOut(); //Nie chce mi sie juz modyfikowac interfejsu, ale mam nadzieje ze rozumiesz ocb :P
}
}
I jeszcze apropo Twojego zapytania - skoro catchujesz dany wyjątek, to znaczy, że umiesz go obsłużyć i poprowadzić metodę tak, aby zadziałała poprawnie ( to znaczy - aby zwróciła oczekiwany rezultat, w tym wypadku potrafi zwrócić IList<Note>. Oczywiście, możesz też wyrzucić wyjątek dalej, ale generalnie rzucanie tego samego wyjątku dalej uważam za antipattern, bo można to po prostu złapać gdzieś wyżej, zamiast łapać po dwa razy. )
Reasumując:
1.
Wyjątki sa po to, by wskazać, że coś jest poza normalnym działaniem danego obiektu/metody.
2. Kod, który wywołuje daną metodę,
powinien sam na podstawie interfejsu który calluje ocenić, czy potrafi daną sytuacje wyjątkową obsłużyć.
3. Po obsłużeniu wyjątku, jesteśmy zobowiązani prowadzić daną metodę normalnie dalej , co oznacza, że musimy zwrócić dany typ danych ( albo wywołać inny wyjątek :P )
Uff. Mam nadzieję , że pomogłem xD
Odpowiedź z cytatem
Zakładki