Jeśli piszę skrypt lub program, czy powinienem wypisywać na stderr jego nazwę wraz z ostrzeżeniem lub komunikatem o błędzie? Na przykład:
./script.sh: Warning! Variable "var" lowered down to 10.
lub:
./prog.py: Error! No such file: "file.cfg".
Rozumiem, że generalnie jest to tylko kwestia gustu (zwłaszcza jeśli piszesz własne rzeczy dla siebie), ale zastanawiam się, czy jest w tym coś konwencjonalnego? Wierzę, że większość narzędzi UNIX / Linux zapisuje swoje nazwy, gdy coś się dzieje, więc wydaje się to dobrą rzeczą, ale czy istnieją jakieś wytyczne lub niewypowiedziane zasady, jak to zrobić, a jak nie?
Na przykład, nie zaleca się instalowania plików binarnych pod /usr/bin/
, raczej pod /usr/local/bin/
lub coś innego. Czy istnieją podobne zasady dotyczące wyjścia do stderr? Czy powinienem napisać imię i dwukropek? Lub po prostu „Ostrzeżenie!” i „Błąd!” słowa? Nie mogłem nic znaleźć, ale może ktoś mógłby wskazać mi, gdzie mam o tym przeczytać.
To pytanie dotyczy trochę praktyk programistycznych, ale pomyślałem, że jest bardziej odpowiednie tutaj niż na przepełnieniu stosu , ponieważ dotyczy tradycji UNIX / Linux, a nie programowania w ogóle.
źródło
no such file
kto wie, który program jest wfoo | bar | baz
potoku.Odpowiedzi:
Powszechną praktyką jest zapisywanie 0. argumentu przekazanego do programu w C
main
i użycie go jako parametru dlaperror
- dla prostych programów:nazwij ten program „foo”, a jego uruchomienie ilustruje tę kwestię:
Skomplikowane programy mogą dodawać do tekstu (lub używać tylko nazwy pliku bez ścieżki), ale zachowanie nazwy programu pozwala dowiedzieć się, skąd pochodzi niewłaściwie działający program.
Nie ma powszechnie akceptowanego schematu komunikatów o błędach, ale niektóre powszechnie używane programy (takie jak gcc) dodają kategorię komunikatów, taką jak „Błąd” lub „Ostrzeżenie”. Oto przykład z jednego z moich dzienników kompilacji:
W tym przykładzie gcc oddziela pola dwukropkami i dodaje kategorię „ostrzeżenie” po nazwie pliku, numerze wiersza, numerze kolumny - i przed rzeczywistym komunikatem. Istnieje jednak kilka odmian, co utrudnia programom (takim jak emac-vi ) analizowanie informacji.
W przypadku kompilatorów użycie kategorii w komunikacie ułatwia wykrycie błędów krytycznych (które mogą nie być natychmiastowe ) i ostrzeżeń. Jeśli twój program kończy działanie z błędem, niewiele mówi, że niektóre są naprawdę ostrzeżeniami, a niektóre błędami. Ale gdy zachowuje się inaczej (lub działa mniej więcej), kategoria pomaga zdiagnozować napotkany problem.
źródło
Jeśli program jest wywoływany jako część skryptu, w którym wywoływane jest wiele innych programów, a jeśli nie wypisuje swojej nazwy, użytkownicy będą mieli trudności z ustaleniem, skąd pochodzi błąd.
(Jeśli błąd jest nieoczekiwanym warunkiem wewnętrznym, który może wymagać debugowania, potrzebujesz jeszcze więcej informacji: nie tylko nazwy programu, ale pliku źródłowego i numeru wiersza i ewentualnie śledzenia wstecznego).
źródło