Rozważ następującą klasę:

public class ComponentA
{
    public ComponentB ComponentB { get; set; }

    public ComponentA(ComponentC componentC) { ... }
}

Kiedy rozpatruję ComponentA, Castle prawidłowo wstrzykuje zarówno ComponentB, jak i ComponentC.

Jeśli jednak wystąpi problem z utworzeniem wystąpienia ComponentB, połknie on wyjątek, powodując opóźnione błędy (NullReferenceException).

Rozumiem różnicę między obydwoma podejściami, ale czy można sprawić, że to się nie powiedzie (lub przynajmniej zarejestrować pełny wyjątek), gdy wystąpi problem z wstrzykniętą właściwością?

3
Diego Mijelshon 19 lipiec 2011, 02:00

2 odpowiedzi

Najlepsza odpowiedź

Na podstawie odpowiedzi Mauricio na pytanie połączone przez Phila utworzyłem StrictComponentActivator, który nie połyka wyjątku, nawet jeśli zależność jest opcjonalna.

Działa zgodnie z oczekiwaniami.

1
Community 23 maj 2017, 15:34

Uważam, że jest to oczekiwane zachowanie, a AFAIK nie da się tego obejść.

Opcją może być użycie prywatnego elementu członkowskiego dla ComponentB, który zostanie ustawiony na domyślną implementację (która zgłasza wyjątek podczas uzyskiwania dostępu, jeśli jest to potrzebne), ale zostanie zastąpiony przez kontener, jeśli rozwiązanie zakończy się pomyślnie.

private ComponentB _b = new ExceptionThrowingComponentB();

public ComponentB B
{
   get { return _b; }
   set { _b = value; }
} 

Jak zauważył svick: nie jest to dobre rozwiązanie.

Edytuj: nie jestem pewien, czy rozumiem, o co to wszystko chodzi, ale wygląda na to, że możesz zmienić to zachowanie:

Dziwne zachowanie Castle Windsor z wtryskiem właściwości i metodą fabryczną

0
Community 23 maj 2017, 13:24
Czym różni się implementacja zgłaszania wyjątków od null, która zawsze zgłasza wyjątek, gdy próbuje go również użyć?
 – 
svick
19 lipiec 2011, 03:21
Ech, masz rację, naprawdę nie ma. Zacząłem od implementacji default/no-op (tak jak zwykle to robię), a potem zdałem sobie sprawę, że chce rzucić wyjątek.
 – 
Phil Sandler
19 lipiec 2011, 03:44