Tôi có nên xuất tên chương trình khi cảnh báo hoặc lỗi xảy ra không?


13

Nếu tôi đang viết một tập lệnh hoặc một chương trình, tôi có nên xuất ra stderr tên của nó cùng với thông báo lỗi hoặc cảnh báo không? Ví dụ:

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

hoặc là:

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

Tôi hiểu rằng nói chung đó chỉ là vấn đề của hương vị (đặc biệt là nếu bạn tự viết những thứ của riêng mình), nhưng tôi tự hỏi liệu có điều gì thông thường không? Tôi tin rằng hầu hết các tiện ích UNIX / Linux đều viết tên của chúng khi có điều gì đó xảy ra, vì vậy nó có vẻ là một điều tốt, nhưng có bất kỳ hướng dẫn hoặc quy tắc bất thành văn nào để làm điều đó và làm thế nào để không?

Ví dụ: không nên cài đặt nhị phân bên dưới /usr/bin/, thay vào /usr/local/bin/đó hoặc một cái gì đó khác. Có các quy tắc tương tự về đầu ra cho stderr? Tôi có nên viết tên theo sau bởi một dấu hai chấm? Hoặc chỉ là "Cảnh báo!" và "Lỗi!" từ ngữ? Tôi không thể tìm thấy bất cứ điều gì nhưng có lẽ ai đó có thể chỉ cho tôi nơi để đọc về nó.

Câu hỏi này là một chút về thực hành lập trình, nhưng tôi nghĩ rằng nó phù hợp hơn ở đây hơn là trên stackoverflow , vì đó là về truyền thống UNIX / Linux và không phải là lập trình nói chung.


5
Tên chương trình có thể hỗ trợ gỡ lỗi ngẫu nhiên no such filetừ những người biết chương trình nào trong một foo | bar | bazđường ống dẫn.
thrig

@thrig Cảm ơn, điểm tốt. Của tôi không phải là đường ống, nhưng ai biết được. Đoán tốt hơn là bám vào hành vi tiêu chuẩn.
gsarret

Câu trả lời:


16

Đó là thực tế phổ biến để lưu đối số thứ 0 được truyền cho chương trình C mainvà sử dụng tham số đó làm tham số cho perror- cho các chương trình đơn giản:

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

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

gọi chương trình đó là "foo" và chạy nó minh họa điểm:

> ./foo
./foo: Cannot allocate memory

Các chương trình phức tạp có thể thêm vào văn bản (hoặc chỉ sử dụng tên tệp mà không có đường dẫn), nhưng việc giữ tên chương trình cho phép bạn tìm thấy một chương trình hoạt động sai xuất phát từ đâu.

Không có sơ đồ được chấp nhận phổ biến cho các thông báo lỗi, nhưng một số chương trình được sử dụng rộng rãi (như gcc) thêm một danh mục thông báo như "Lỗi" hoặc "Cảnh báo". Đây là một ví dụ từ một trong các bản ghi của tôi:

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

Trong ví dụ này, gcc tách các trường bằng dấu hai chấm và thêm danh mục "cảnh báo" sau tên tệp, số dòng, số cột - và trước thông báo thực tế. Nhưng có một số biến thể, làm cho các chương trình (như vi-like-emacs ) trở nên phức tạp để phân tích thông tin.

Đối với trình biên dịch, sử dụng một danh mục trong thông báo giúp dễ dàng phát hiện các lỗi nghiêm trọng (có thể không gây tử vong ngay lập tức ) và cảnh báo. Nếu chương trình của bạn thoát khỏi một lỗi, nó không thêm nhiều để nói rằng một số thực sự là cảnh báo và một số là lỗi. Nhưng khi nó hoạt động khác đi (hoặc tiếp tục hoạt động nhiều hơn hoặc ít hơn), danh mục giúp chẩn đoán vấn đề gặp phải.


Cảm ơn bạn cho một ví dụ, tôi nhận được điểm. Thế còn "Lỗi" và "Cảnh báo", chúng có làm lộn xộn đầu ra không?
gsarret

Chỉnh sửa cuối cùng của bạn - chính xác những gì tôi đã suy nghĩ về! Việc sử dụng là gì nếu nó thoát ngay sau thông báo err? Cảm ơn một lần nữa.
gsarret

8

Nếu một chương trình được gọi là một phần của tập lệnh trong đó nhiều chương trình khác được gọi và nếu nó không in tên của nó, thì người dùng sẽ khó tìm ra lỗi xuất phát từ đâu.

(Nếu lỗi là một số điều kiện nội bộ không mong muốn có thể yêu cầu gỡ lỗi, bạn muốn có thêm thông tin: không chỉ tên chương trình, mà cả tệp nguồn và số dòng và có thể là một backtrace.)


Cảm ơn. Tôi thường tự viết chương trình cho mình (mô phỏng số) để chỉ có một người dùng, tuy nhiên tôi có thể chia sẻ chúng một ngày. Chúng cũng không phức tạp (ít nhất là vậy), vì vậy không có vấn đề gì trong việc tìm nguồn lỗi, nhưng nhờ gợi ý, có thể hữu ích trong tương lai.
gsarret
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.