Co myślicie o wyjątkach pamiętających dane i obiekty?

Spotkałem się często z bibliotekami, w których klasy które można by nazwać dziećmi (nie w kontekście dziedziczenia, tylko tego która klasa jest factory której) pamiętają referencje do swojego rodzica.

Przykład, to choćby DOM z JS'a, gdzie mając dowolny child, można złapać jego parent.
Albo przykład z tkintera, gdzie łapiąc komponent dodany do okna, można z tego dziecka wyciągnąć to okno.

Piszę sobie właśnie libkę do regexpów, jak część z was już wiem, i zastanawiam się czy nie dodać właśnie takiego patternu, w stylu:

$pattern = Pattern::of("\d+");
$matcher = $pattern->match("abc");

try {
  $matcher->first();
} catch (SubjectNotMatchedException $ex) {
  $ex->getPattern(); // tutaj wzięcie patternu, zamiast z $pattern
}

Co o tym myślicie? Useful? Czy raczej szkoda brudzić libkę takim czymś

Za bardzo nie widzę zalet. Jak ktoś chce coś zawrzeć coś do wyjątku to zawsze można owrapować. Z wad:

• bardziej skomplikowany kod
• niepotrzebne przedłużanie czasu życia obiektu. Przy dużych drzewach takie zachowanie może ładnie spowolnić gc

Nie wiem jak tam w php ale w wielu językach wyjątki mogą lecieć przez rpc i powinny być w pełni serializowalne. Dodanie referencji do żywego obiektu w wyjątku znacznie to komplikuje. Czasem ludzie już niezależnie od języka robią logowanie nieobsłużonych błędów w prosty sposób serializując cały wyjątek jaki poleciał, mają wtedy kompletny message, stacktrace itp. W tym przypadku do logów wciągnięte by było całe mnóstwo obiektów z twojej biblioteki.
Moim zdaniem - nie. Obiekt wyjątku powinien być jak najmniejszy i najprostszy.
DOM to całkiem inna sytuacja, nawet bym jej tu nie przywoływał

Tj. opakowujesz jakiś obiekt w wyjątek i leeeci w górę drzewka po to, żeby ktoś taki wyjątek złapał i zrobił z tym obiektem coś?
To mi się kojarzy z bardzo niebezpiecznym programowaniem na wyjątkach, ale w uzasadnionych (żeby nie powiedzieć "wyjątkowych" ;) ) sytuacjach pewnie bym dopuścił takowy twór. Tylko właśnie chodzi o to, że to musi być mocno uzasadniona sytuacja, tak ogólnie takowe działania mi się nie podobają.

wartek01 napisał(a):

Tj. opakowujesz jakiś obiekt w wyjątek i leeeci w górę drzewka po to, żeby ktoś taki wyjątek złapał i zrobił z tym obiektem coś?

Nie.

Mogłoby to zostać użyte do programowania wyjątkami, jeśli ktoś byłby na tyle nieroztropny żeby tego użyć, ale nie taka jest idea tego.

Chodzi o to, żeby gdzieś na dole drabinki, jak poleci wyjątek, żeby móc np dołożyć orginalny pattern do message'a.

Riddle napisał(a):

Chodzi o to, żeby gdzieś na dole drabinki, jak poleci wyjątek, żeby móc np dołożyć orginalny pattern do message'a.

Właśnie o tym piszę.

Ja rozumiem to tak:
SubjectNotMatchedException - pytanie, czy powinien zawierać w sobie pattern, tak, żeby wywołanie $matcher->first() nim rzucało tak, żeby użytkownik mógł sobie to przechwycić w dowolnym momencie i sprawdzić, co to był za pattern.

W ekosystemie Javy rozjaśnieniem jest interefjs Serializable, to dośc dobrze wskazuje co jest nośnikiem danych (można by myśleć o zamrożeniu w komunikacie/wyjątku), a jego brak, obiekt jest żywy, dynamiczny, z powiązaniami do podobnych sobie - niedopuszczalne

Więc w pierwszym przypadku "może", w drugi "nie", choć jakieś dane intetyfikacyjne ewentualnie