W encji Rate
mam taki konstruktor:
public Rate(int productId, Guid customerId, int stars)
{
Guard.InRange(stars, 1, 6, "Liczba gwiazek nie jest poprawna."); // rzuca wyjątek z kodem NotValid
if (productId <= 0)
throw new MyStoreException(Code.NotSpecified, "ID produktu nie jest poprawne.");
if (customerId == Guid.Empty)
throw new MyStoreException(Code.NotSpecified, "ID klienta nie jest poprawne.");
ProductId = productId;
CustomerId = customerId.ToString();
Stars = stars;
}
Chciałbym tłumaczyć wyjątki z warstwy domeny na jakieś czytelne odpowiedzi dla użytkownika. O ile ma to sens w przypadku, gdy użytkownik poda (w jakiś sposób) niepoprawną ilość gwiazdek i walidacja tego nie wyłapie, o tyle w sytuacji, gdy ID produktu albo klienta nie jest poprawne, raczej sensu to nie ma, bo przyczyną tych błędów będą prawdopodobnie luki w samej aplikacji (np. binding nie zadziała), a nie użytkownik. Co użytkownik dowiedziałby się z informacji, że ID klienta nie jest poprawne
? Zrobiłem to tak, że w domenie rzucam wyjątki z kodem NotValid
, które są tłumaczone na Bad Request
i wyjątki z kodem NotSpecified
, które są tłumaczone na Internal Server Error
(w odpowiedzi jakaś ogólna informacja, że coś nie działa, a sama wiadomość z wyjątku idzie do logów). Pytania:
- Czy ma to sens? Nie byłoby lepiej zawsze zwracać 400 albo 500?
- Czy nie lepiej byłoby przekazywać do konstruktora encje, zamiast tylko ich ID? np.
Rate(Product product, Customer customer, int stars)
?