Czy warto dodawac `if`a do message'ów wyjątków w bibliotece?

W niektórych miejscach w bibliotece, rzucany jest wyjątek z następującym message'm:

Expected to perform at most at most 1 replacement(s), but more than 1 replacement(s) would have been performed

kod który go rzuca wygląda tak:

return new self("Expected to perform $limitPhrase $expected replacement(s), but more than $expected replacement(s) would have been performed");

nie trudno byłoby odmienić rzeczownik, albo ifem, albo jakimś innym sprytnym rozwiązaniem, tak żę message wyglądałyby tak:

Expected to perform at most at most 0 replacements, but more than 1 replacements would have been performed

Expected to perform at most at most 1 replacement, but more than 1 replacement would have been performed

Expected to perform at most at most 2 replacements, but more than 1 replacements would have been performed

Tylko właśnie, pytanie czy jest sens to dodawać? Jakby nie patrzeć ten kod nie jest potrzebny do działania. Jak myślicie?

Wydaje mi się, że szkoda na to czasu. Jak masz go za dużo wolnego, to lepiej poświęć go na rozwijanie innych elementów apki/biblioteki.

Poza tym - zawsze można znaleźć rozwiązanie kompromisowe. Zamiast zastanawiać się, czy odmieniać znaleziono 1 błąd ale 2 błędy to można zachować się jak rasowy cwaniak i napisać Liczba znalezionych błędów: X ;)

Samo budowanie messagów ma sens jeśli taki message przyśpiesza inwestygację. W tym wypadku to zbędna pierdoła, bo każdy wie czym jest 0 replacements. Szkoda komplikować kod

cerrato napisał(a):

Zamiast zastanawiać się, czy odmieniać znaleziono 1 błąd ale 2 błędy to można zachować się jak rasowy cwaniak i napisać Liczba znalezionych błędów: X ;)

Za czasów, jak implemntacja polskich liter była niestabilna / nie było jej wcale na niektórym sprzęcie, też się dobierało treśc komunikatów. Najbardziej zakazanym słowem było żądanie
Eh, były czasy

Nie wiem czy realne, czy satyryczne, ale podobno wtedy ktoś "Press any key " przetłumaczył na ślunśką gadkę "Klepnij ino guzek"

ZrobieDobrze napisał(a):

cerrato napisał(a):

Zamiast zastanawiać się, czy odmieniać znaleziono 1 błąd ale 2 błędy to można zachować się jak rasowy cwaniak i napisać Liczba znalezionych błędów: X ;)

Za czasów, jak implemntacja polskich liter była niestabilna / nie było jej wcale na niektórym sprzęcie, też się dobierało treśc komunikatów. Najbardziej zakazanym słowem było żądanie
Eh, były czasy

Nie wiem czy realne, czy satyryczne, ale podobno wtedy ktoś "Press any key " przetłumaczył na ślunśką gadkę "Klepnij ino guzek"

Nikt normalny nie rzuca wyjątków z message'ami innymi niż angielski.

Jeśli komunikat o błędzie jest dla użytkownika końcowego, czyli jeśli wyjątek jest częścią normalnej obsługi spodziewanych błędów, to wyjątek powinien nieść w sobie wszystkie surowe dane jako osobne pola, a formatowaniem komunikatu powinna się zajmować osobna funkcja, zrobiona specjalnie do tego. I ta funkcja może wtedy również zajmować się tłumaczeniem (czyli np. wyszukaniem szablonu komunikatu w odpowiednim zasobie). Natomiast sam message w wyjątku nie jest dla użytkownika końcowego a dla programisty. Dlatego może być tam cokolwiek co pomoże programiście zrozumieć co się stało i naprawić błąd.

Niestety często widzę taki brzydki zwyczaj olewania obsługi błędów przez programy posiadające mechanizm wyjątków - zamiast faktycznie obsłużyć błąd i napisać użytkownikowi coś użytecznego, to programisci rzucają wyjątek (ze stacktracem i mało zrozumiałym, często niekompletnym komunikatem) na konsole i myślą że to wystarczy. Jeśli apka nie znalazła jakiegoś pliku to naprawdę nie obchodzi mnie w której linii programu nie udało się jakieś File.open.