Haruskah saya menampilkan nama program ketika peringatan atau kesalahan terjadi?


13

Jika saya menulis skrip atau program, haruskah saya menampilkan stderr namanya bersama dengan peringatan atau pesan kesalahan? Sebagai contoh:

./script.sh: Warning! Variable "var" lowered down to 10.

atau:

./prog.py: Error! No such file: "file.cfg".

Saya mengerti bahwa secara umum itu hanya masalah selera (terutama jika Anda menulis sendiri barang-barang Anda), tetapi saya bertanya-tanya apakah ada yang konvensional dengan itu? Saya percaya sebagian besar utilitas UNIX / Linux menulis nama mereka ketika sesuatu terjadi, jadi sepertinya hal yang baik, tetapi apakah ada pedoman atau aturan yang tidak diucapkan bagaimana melakukan itu dan bagaimana tidak?

Misalnya, tidak disarankan memasang binari di bawah /usr/bin/, melainkan di bawah /usr/local/bin/atau yang lainnya. Apakah ada aturan yang sama tentang output ke stderr? Haruskah saya menulis nama yang diikuti dengan tanda titik dua? Atau hanya "Peringatan!" dan "Kesalahan!" kata-kata? Saya tidak dapat menemukan apa pun, tetapi mungkin seseorang dapat mengarahkan saya ke tempat untuk membacanya.

Pertanyaan ini sedikit tentang praktik pemrograman, tapi saya pikir lebih tepat di sini daripada di stackoverflow , karena ini tentang tradisi UNIX / Linux dan bukan pemrograman pada umumnya.


5
Nama program dapat membantu men-debug secara acak no such filedari siapa yang tahu program apa yang ada dalam foo | bar | bazpipa.
thrig

@ thrig Terima kasih, poin bagus. Milik saya tidak seharusnya disalurkan, tetapi siapa yang tahu. Kira lebih baik berpegang pada perilaku standar.
gsarret

Jawaban:


16

Merupakan praktik umum untuk menyimpan argumen 0 yang diteruskan ke program C maindan menggunakannya sebagai parameter untuk perror- untuk program sederhana:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
    char *foo = malloc(9999999999L);
    if (foo == 0)
        perror(argv[0]);
    return 0;
}

sebut program itu "foo", dan menjalankannya mengilustrasikan intinya:

> ./foo
./foo: Cannot allocate memory

Program yang rumit dapat ditambahkan ke teks (atau hanya menggunakan nama file tanpa path), tetapi menjaga nama program memungkinkan Anda menemukan dari mana program perilaku buruk berasal.

Tidak ada skema yang diterima secara universal untuk pesan kesalahan, tetapi beberapa program yang banyak digunakan (seperti gcc) menambahkan kategori pesan seperti "Kesalahan" atau "Peringatan". Berikut ini contoh dari salah satu build-log saya:

compiling fld_def (obj_s)
../form/fld_def.c: In function '_nc_Copy_Argument':
../form/fld_def.c:164:14: warning: cast discards 'const' qualifier from pointer target type [-Wcast-qual]
        res = (TypeArgument *)argp;
              ^

Dalam contoh ini, gcc memisahkan bidang dengan titik dua dan menambahkan kategori "peringatan" setelah nama file, nomor baris, nomor kolom - dan sebelum pesan aktual. Tetapi ada beberapa variasi, menjadikannya rumit untuk program (seperti vi-like-emacs ) untuk mengurai informasi.

Untuk kompiler, menggunakan kategori dalam pesan membuatnya mudah untuk mendeteksi kesalahan fatal (yang mungkin tidak langsung berakibat fatal ) dan peringatan. Jika program Anda keluar karena kesalahan itu tidak menambah banyak untuk mengatakan bahwa ada yang benar-benar peringatan dan ada yang kesalahan. Tetapi ketika itu berperilaku berbeda (atau terus bekerja lebih atau kurang) kategori membantu untuk mendiagnosis masalah yang dihadapi.


Terima kasih untuk sebuah contoh, saya mengerti maksudnya. Bagaimana dengan "Kesalahan" dan "Peringatan", apakah mereka mengacaukan hasil?
gsarret

Suntingan terakhir Anda - persis apa yang saya pikirkan! Apa gunanya jika ia keluar setelah pesan err? Terima kasih lagi.
gsarret

8

Jika suatu program dipanggil sebagai bagian dari skrip di mana banyak program lain dipanggil, dan jika tidak mencetak namanya, maka pengguna akan kesulitan untuk mencari tahu dari mana kesalahan itu berasal.

(Jika kesalahannya adalah beberapa kondisi internal tak terduga yang mungkin memerlukan debugging, Anda menginginkan lebih banyak info: bukan hanya nama program, tetapi file sumber dan nomor baris dan mungkin juga backtrace.)


Terima kasih. Saya biasanya menulis program untuk diri saya sendiri (simulasi numerik) jadi hanya ada satu pengguna, namun saya mungkin membaginya suatu hari. Mereka juga tidak begitu rumit (well, setidaknya belum) jadi tidak ada masalah menemukan sumber kesalahan, tapi terima kasih atas petunjuknya, mungkin berguna di masa depan.
gsarret
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.