Uyarı veya hata oluştuğunda programın adını çıkarmalı mıyım?


13

Bir komut dosyası veya program yazıyorsam, adını uyarı veya hata mesajı ile birlikte stderr'e çıkarmam gerekir mi? Örneğin:

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

veya:

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

Genel olarak bunun sadece bir tat meselesi olduğunu anlıyorum (özellikle kendi eşyalarınızı kendiniz yazarsanız), ama bunun için geleneksel bir şey olup olmadığını merak ediyorum? Çoğu UNIX / Linux yardımcı programının bir şey olduğunda adlarını yazdığına inanıyorum, bu yüzden iyi bir şey gibi görünüyor, ancak bunun nasıl yapılacağını ve nasıl yapılacağına dair yönergeler veya konuşulmamış kurallar var mı?

Örneğin, ikili dosyaların altına /usr/bin/, altına /usr/local/bin/veya başka bir şeye kurulması tavsiye edilmez . Stderr'e çıktı konusunda benzer kurallar var mı? İsmi ve ardından iki nokta üst üste yazmalıyım? Veya sadece "Uyarı!" ve "Hata!" kelimeler? Hiçbir şey bulamadım ama belki biri beni nereden okuyacağımı gösterebilir.

Bu soru programlama uygulamaları hakkında biraz, ama oldukça üzerinde daha burada daha uygundur düşünce stackoverflow UNIX / Linux gelenekler hakkında ve genel olarak programlama değil.


5
Program adı, no such filebir foo | bar | bazboru hattında hangi programı bilenlerden rastgele bir hata ayıklamaya yardımcı olabilir .
thrig

@thrig Teşekkürler, iyi bir nokta. Benimki pipetlenmemeli, kim bilir. Sanırım standart davranışa bağlı kalmak daha iyidir.
gsarret

Yanıtlar:


16

Bir C programına iletilen 0. bağımsız değişkeni kaydetmek mainve bunu perrorbasit programlar için - parametresi olarak kullanmak yaygın bir uygulamadır :

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

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

bu programı "foo" olarak adlandırırsanız ve programı çalıştırmanız şu noktayı gösterir:

> ./foo
./foo: Cannot allocate memory

Karmaşık programlar metne ekleyebilir (veya yalnızca yol olmadan dosya adını kullanabilir), ancak program adını korumak, hatalı çalışan bir programın nereden geldiğini bulmanızı sağlar.

Hata iletileri için evrensel olarak kabul edilen bir düzen yoktur, ancak yaygın olarak kullanılan bazı programlar (gcc gibi) "Hata" veya "Uyarı" gibi bir ileti kategorisi ekler. Oluşturma günlüklerimden birinden bir örnek:

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;
              ^

Bu örnekte, gcc alanları iki nokta üst üste işaretiyle ayırır ve dosya adından, satır numarasından, sütun numarasından sonra ve gerçek iletiden önce bir "uyarı" kategorisi ekler. Ancak, programların ( vi benzeri emacs gibi ) bilgileri ayrıştırmasını karmaşık hale getiren çeşitli varyasyonlar vardır .

Derleyiciler için, iletide bir kategori kullanmak ölümcül hataları ( hemen ölümcül olmayabilir ) ve uyarıları algılamayı kolaylaştırır . Programınız bir hatadan çıkarsa, bazılarının gerçekten uyarı ve bazılarının hata olduğunu söylemek fazla bir şey eklemez. Ancak farklı davrandığında (veya daha fazla veya daha az çalışmaya devam ettiğinde), kategori karşılaşılan sorunun teşhis edilmesine yardımcı olur.


Bir örnek için teşekkür ederim, anladım. Peki ya "Hata" ve "Uyarı", çıktıları dağıtıyor mu?
gsarret

Son düzenlemeniz - tam olarak düşündüğüm şey! Hata mesajından hemen sonra çıkarsa ne işe yarar? Tekrar teşekkürler.
gsarret

8

Bir program, diğer birçok programın çağrıldığı bir komut dosyasının parçası olarak çağrılırsa ve adını yazdırmazsa, kullanıcılar hatanın nereden geldiğini bulmakta zorlanırlar.

(Hata, hata ayıklama gerektirebilecek beklenmedik bir iç durumsa, daha da fazla bilgi istersiniz: sadece program adı değil, bir kaynak dosyası ve satır numarası ve muhtemelen bir geri izleme.)


Teşekkürler. Genellikle kendim için programlar yazıyorum (sayısal simülasyon), bu yüzden sadece bir kullanıcı var, ancak bir gün bunları paylaşabilirim. Ayrıca o kadar karmaşık değiller (en azından henüz), bu nedenle hatanın kaynağını bulmakta sorun yoktur, ancak ipucu için teşekkürler, gelecekte yararlı olabilir.
gsarret
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.