Tất cả các ngôn ngữ có thể có lỗi ngữ nghĩa và logic?


7

Tôi đã đọc về PHP và nhiều tác giả đề cập đến các lỗi ngữ nghĩa và logic riêng biệt. Như một ví dụ về lỗi ngữ nghĩa, họ đưa ra một hàm được gọi với số lượng tham số không chính xác: điều này sẽ không bị trình phân tích cú pháp bắt, nhưng sẽ đưa ra lỗi khi chạy.

Tuy nhiên, trong các ngôn ngữ như C ++, trình biên dịch này sẽ bị bắt bởi trình biên dịch. Tôi sẽ nói rằng đó là một lỗi cú pháp sau đó. Sự khác biệt sau đó giữa một lỗi ngữ nghĩa và logic là gì?

Ví dụ, trong Cách suy nghĩ như một nhà khoa học máy tính , tác giả sử dụng "lỗi logic" và "lỗi ngữ nghĩa" thay thế cho nhau. Mặt khác, trong Visual Basic .NET. Primer Plus , "lỗi logic" được tách ra khỏi "lỗi ngữ nghĩa".


Ngoài ra, bản sao của: lập trình

Tôi biết các khuyết điểm, vấn đề là nó không áp dụng cho tất cả các ngôn ngữ lập trình theo cùng một cách, như đã đề cập trong các câu trả lời. Tôi đã không hỏi lỗi LÀ GÌ, NỀN TẢNG VÀ logic. Một số tác giả coi semanthic là lỗi logic, một số thì không.

1
Gọi một hàm với các đối số sai không phải là một lỗi cú pháp. Đây là một loại- và, do đó, một lỗi ngữ nghĩa.

Một số người bao gồm ngữ nghĩa tĩnh (tên, loại, ...) trong thuật ngữ "cú pháp", biểu thị hiệu quả mọi thứ có thể (hoặc đúng hơn là) được trình biên dịch kiểm tra là "cú pháp". "Semantic" là những gì chi phối việc thực hiện chương trình, ví dụ như gửi phương thức động. Tôi không biết một định nghĩa chính thức về "lỗi logic". Có lẽ bạn muốn phân biệt giữa sai lầm, lỗi và lỗi. Lỗi logic (do lập trình viên) gây ra lỗi (trong chương trình) có thể gây ra lỗi (khi chạy) mà trình biên dịch không thể loại trừ (ví dụ: NPE, div-by-zero, ...).
Raphael

Câu trả lời:


7

Tôi nghĩ rất có thể là lời giải thích cho một số tác giả sử dụng "lỗi logic" và "lỗi ngữ nghĩa" có thể hoán đổi cho nhau và một số tác giả vẽ một sự khác biệt chỉ đơn giản là họ không một định nghĩa được chấp nhận phổ biến chính xác, và vì vậy mọi người đang sử dụng thuật ngữ hơi khác. Tôi sẽ không bị treo lên nó.

Cả "logic" và "ngữ nghĩa" đều ngụ ý một cái gì đó liên quan đến ý nghĩa của lập trình, vì vậy sẽ dễ dàng coi chúng là như nhau.

Nếu tôi có một sự khác biệt, một điều hữu ích tôi có thể thấy là lỗi logic là khi chương trình kết thúc có ý nghĩa khác với những gì lập trình viên dự định và một lỗi ngữ nghĩa là khi chương trình kết thúc không có ý nghĩa gì (nhất quán) ở tất cả. Với các định nghĩa đó, bạn có thể coi lỗi logic là siêu lỗi của ngữ nghĩa hoặc lỗi logic đó loại trừ các lỗi dẫn đến chương trình không nhất quán.

Ví dụ: mã giả sau đây chỉ chứa lỗi logic:

x = read_number_from_user("x: ")
y = read_number_from_user("x: ")
print("The product of x and y is: ")
print(stringify(x + y))

Ý nghĩa của chương trình này (chỉ được thực hiện theo nguyên trạng và không xem xét ý định của lập trình viên) là hoàn toàn đơn giản và nhất quán. Nhưng nó không có nghĩa là những gì lập trình viên dự định.

OTOH, mã giả sau đây có lỗi ngữ nghĩa:

name = read_string_from_user("What is your name?")
print(name + 1)

Ít nhất, nó sẽ làm nếu chúng ta giả sử rằng việc thêm một chuỗi và một số không có nghĩa gì cả. Trong các ngôn ngữ như PHP, nó nghĩa gì đó và đây sẽ không phải là một lỗi ngữ nghĩa.

Ví dụ của bạn về một lỗi ngữ nghĩa trong PHP khi gọi một hàm có số lượng tham số không chính xác thực sự rất thú vị, bởi vì việc bạn có nên gọi đó là lỗi ngữ nghĩa hay không (với định nghĩa tôi đang sử dụng).

Các hàm được định nghĩa động khi chạy trong PHP. Vì vậy, việc gọi một hàm với số lượng tham số không chính xác có thể được coi là lỗi logic; có lẽ câu lệnh bao gồm sai đã được thực thi, làm cho một hàm khác có cùng tên được bao gồm so với câu lệnh được gọi là. Ngay cả khi không, việc gọi một hàm với số lượng đối số sai có nghĩa là một cái gì đó ; nó có nghĩa là tra cứu hàm với tên này và truyền cho nó các đối số. Nó chỉ hoạt động trong thời gian chạy mà hóa ra trình thông dịch không thể thực hiện các yêu cầu đó; cũng x / ycó nghĩa là một cái gì đó, nhưng có thể không thể thực hiện nếu yxảy ra bằng 0 khi chạy.

Cuối cùng, cách bạn phân loại lỗi bằng cách sử dụng một sự khác biệt như lỗi tôi đang mắc phải ở đây giữa lỗi logic và ngữ nghĩa (ngay cả khi nó không chính xác là lỗi tôi đang làm) phụ thuộc rất nhiều vào ngôn ngữ cụ thể mà bạn đang nói và cách bạn gán ý nghĩa cho các chương trình trong ngôn ngữ . Các ngôn ngữ được sử dụng phổ biến nhất không có cách gán ý nghĩa chuẩn cho chương trình của họ, điều đó có nghĩa là mọi người sử dụng một cách làm hơi khác (mặc dù cách giải thích của mọi người sẽ đồng ý rất chặt chẽ về hầu hết các hiệu ứng hoạt động) và sẽ phân tích "logic" Phân biệt "so với" ngữ nghĩa "khác nhau.

Một cách nhìn tương tự khác có thể nói rằng các lỗi ngữ nghĩa là bất cứ điều gì khiến ngôn ngữ lập trình từ chối chương trình là không hợp lệ (ngoài các lỗi cú pháp, mặc dù một lần nữa bạn có thể gọi đó là một tập hợp các lỗi ngữ nghĩa nếu bạn muốn). Nếu ngôn ngữ lập trình chấp nhận chương trình thì nó có nghĩa là gì đó và nếu nó bị lỗi trong thời gian chạy thì đó là kết quả của lỗi logic. Điều này là khá nhiều việc chỉ định thực hiện ngôn ngữ lập trình (trình thông dịch, trình biên dịch + hệ thống thời gian chạy, bất cứ điều gì) như định nghĩa của các chương trình có nghĩa là gì.


3

Có thể phân biệt nhiều loại lỗi trong các chương trình dựa trên điểm mà chúng biểu hiện. Một số danh mục không phát sinh trong một số bối cảnh nhất định (tùy thuộc vào ngôn ngữ lập trình, về cách thiết kế chương trình, về cách sử dụng chương trình. Thuật ngữ thay đổi rất nhiều giữa các cộng đồng. Tôi sẽ hiển thị một loại hình của các loại chính; hãy nhớ rằng

  • có những quy trình công việc trong đó một số loại này sẽ không được áp dụng;
  • có những quy trình công việc mà ở đó thuận tiện để tạo sự khác biệt;
  • lỗi tương tự có thể kết thúc trong các loại khác nhau tùy thuộc vào ngôn ngữ lập trình và các công cụ được sử dụng;
  • những người khác nhau có những thuật ngữ khác nhau, những cái tên tôi đưa ra là hợp lý nhưng không có nghĩa là đồng thuận.

Bạn có thể phân biệt các loại lỗi khác nhau dựa trên điểm mà chúng được chú ý.

  1. Lỗi cú pháp
    Trình biên dịch hoặc trình thông dịch cho bạn biết rằng những gì bạn đã viết thậm chí không có ý nghĩa. Trong hầu hết các ngôn ngữ, đây là một lỗi nghiêm trọng, sẽ không cho phép chương trình bắt đầu được thực thi.
    Ví dụ: thiếu dấu ngoặc đơn.

  2. Lỗi loại tĩnh và lỗi trình biên dịch khác Trình biên
    dịch hoặc trình thông dịch cho bạn biết rằng trong khi nó hiểu những gì bạn yêu cầu, điều đó không có nghĩa. Sự khác biệt giữa lỗi cú pháp và các loại lỗi trình biên dịch khác là vấn đề thiết kế trình biên dịch nội bộ, hoặc đôi khi là thiết kế của ngôn ngữ lập trình.
    Ví dụ: sử dụng một biến chưa được xác định (điều này thường được coi là lỗi cú pháp nhưng không phải luôn luôn)

    Trong các ngôn ngữ gõ tĩnh, trình biên dịch từ chối các chương trình thử một số loại hoạt động không hợp lệ. Trong các ngôn ngữ được gõ động, các lỗi như vậy là lỗi thời gian chạy, có thể gây tử vong hoặc không. Ví dụ: cố gắng chia một số nguyên cho một chuỗi.

  3. Lỗi khởi động
    Đây là loại lỗi đầu tiên được tiết lộ cho người điều hành chương trình chứ không phải người thực hiện chương trình.
    Chương trình sẽ không bắt đầu hoặc sẽ không đạt đến trạng thái thực sự làm gì đó.
    Ví dụ: cố gắng sử dụng một thư viện bên ngoài không có trên hệ thống.
    Ví dụ: bất kỳ cú pháp hoặc lỗi biên dịch trong ngôn ngữ diễn giải (nơi lập trình viên phân phối mã nguồn).

  4. Lỗi thời gian chạy nghiêm trọng
    Tại một số điểm, chương trình ngừng hoạt động.
    Ví dụ: vi phạm quyền truy cập bộ nhớ (cố gắng truy cập bộ nhớ không được phân bổ cho chương trình)
    Lưu ý rằng các chương trình đủ phức tạp có thể cố gắng nắm bắt bất kỳ lỗi nào, biến chúng thành lỗi có thể phục hồi.

  5. Bất ngờ, nhưng lỗi thời gian chạy có thể phục hồi
    Một số thành phần của chương trình ngừng hoạt động, nhưng chương trình vẫn tiếp tục. Ví dụ: hết bộ nhớ (nếu chương trình được thiết kế để xử lý việc này một cách duyên dáng)
    Ví dụ: một quy trình trong ứng dụng đa xử lý gặp sự cố, nhưng các quy trình khác tiếp tục chạy

  6. Lỗi thời gian chạy dự kiến
    Một số điều kiện lỗi được mong đợi, nhưng nó đã được lập trình cho. Đây chỉ là hành vi bình thường, phản ứng với một sự kiện bên ngoài mà bằng cách nào đó là Bad bad nhưng điều đó có thể xảy ra. Khi bạn xem xét toàn bộ chương trình, đây không phải là lỗi thực sự.
    Ví dụ: không tìm thấy tệp
    Ví dụ: ngắt kết nối mạng
    Ví dụ: đầu vào của người dùng không hợp lệ

  7. Lỗi lập
    trình Chương trình đang làm một cái gì đó, nhưng đó không phải là những gì nó phải làm theo đặc điểm kỹ thuật của nó. Có một sự khác biệt giữa những gì lập trình viên dự định làm và ý nghĩa của mã nguồn.
    Ví dụ: một ứng dụng web được cho là cho phép bạn tải lên một tệp, nhưng nó không hoạt động trên các tên tệp không gian; ứng dụng từ chối các tập tin và tiếp tục làm việc.
    Ví dụ: một chương trình được thiết kế để nhân một số số trả về kết quả, nhưng phép toán không được thực hiện đúng.

  8. Lỗi đặc tả
    Chương trình đang làm một cái gì đó, và phù hợp với đặc điểm kỹ thuật hoặc tài liệu của nó. Tuy nhiên, theo phản ánh, hành vi của chương trình trong tình huống này là không tốt. (Không phải là tốt, dĩ nhiên là một phán đoán chủ quan.)
    Ví dụ: thành phần 1 mong đợi một danh sách tên tệp được phân tách bằng dấu cách. Thành phần 2 gửi cho nó một tên tệp duy nhất chứa khoảng trắng. Hai thành phần không được thiết kế cẩn thận để làm việc cùng nhau.
    Ví dụ: một chương trình dự đoán thời tiết thông báo mưa sẽ không đến, bởi vì mô hình hóa thế giới vật lý của nó không đủ tốt.

Một điều khá điển hình là coi 2 trận4 là lỗi ngữ nghĩa và 7 trận8 là lỗi logic. (Tuy nhiên, lưu ý một lần nữa rằng thuật ngữ có thể thay đổi.) Lỗi thời gian chạy có thể phục hồi không phải là lỗi của toàn bộ chương trình, nhưng có thể được coi là lỗi thời gian chạy của một phần của nó.

Có một thuật ngữ khác nhau cho rằng

  • Các lỗi ngữ nghĩa là những gì trình biên dịch có hệ thống kiểu tĩnh thường mắc phải hoặc điều gì sẽ khiến hệ thống thời gian chạy bảo vệ trực tiếp bị hủy bỏ chương trình với một ngoại lệ không phải do sự kiện bên ngoài (ví dụ: phương thức không được tìm thấy trái ngược với tệp không tìm);
  • lỗi logic là những gì sẽ không được bắt.

Đây có thể là một sự phân biệt khá chính xác khi bạn xem xét một ngôn ngữ cụ thể và một trình kiểm tra loại cụ thể. Tuy nhiên, khi mọi người sử dụng các thuật ngữ này, họ thường có một ý tưởng rất thiếu chính xác về trình biên dịch giả định đó sẽ là gì. Ví dụ: nếu bạn đang lập trình bằng Java, việc chuyển số lượng đối số sai sẽ bị trình biên dịch bắt. Nếu bạn đang lập trình bằng PHP, nó sẽ bị hệ thống thời gian chạy bắt. Nếu bạn đang lập trình trong Perl, có thể nó sẽ không bị bắt (trong trường hợp không có bất kỳ khai báo đối số nào, các đối số phụ sẽ bị bỏ qua và các đối số bị thiếu sẽ tạo ra một giá trị mặc định).

Hoặc, để đưa ra một ví dụ khác: giả sử bạn có một mảng 10 phần tử và bạn cố gắng truy cập vào phần thứ 11. Trong một số ngôn ngữ như C, điều này khiến chương trình của bạn truy cập vào một số vùng bộ nhớ không liên quan, dẫn đến hành vi không thể đoán trước. Trong các ngôn ngữ khác, điều này gây ra một ngoại lệ được ném ra; tùy thuộc vào việc lập trình viên có mong đợi điều này hay không, đây có thể là một lỗi ngữ nghĩa (lập trình viên dự kiến ​​rằng chỉ số có thể nằm ngoài giới hạn nhưng không kiểm tra tình huống đó), một lỗi logic (lập trình viên đã lầm tưởng rằng chỉ mục sẽ luôn hợp lệ ) hoặc hoàn toàn không phải là lỗi (lập trình viên đã dựa vào ngoại lệ để kiểm tra xem chỉ số mảng có nằm trong giới hạn của mảng không).

Đạo đức của câu chuyện là những phân loại này rất khác nhau. Đừng coi trọng lỗi nào được đưa vào danh mục nào của tác giả. Điều quan trọng là phải hiểu mối quan hệ giữa những gì bạn viết và những gì chương trình nên làm. Là một lập trình viên, công việc của bạn là mang lại khoảng cách lớn giữa những gì tôi viếtnhững gì tôi muốn nói . Nếu có thứ gì đó rơi vào khoảng trống, đừng treo lên để gắn nó với nhãn; tập trung vào việc hiểu những gì đang xảy ra và làm thế nào để khắc phục nó.


"Những gì bạn viết thậm chí không có ý nghĩa" so với "điều đó không có ý nghĩa" không phải là một sự phân biệt rõ ràng. Tôi nghĩ sẽ giúp nói "phân tích CFG thất bại -> lỗi cú pháp. Phần còn lại (trong trình biên dịch) -> ngữ nghĩa tĩnh". Hơn nữa, tôi nghĩ rằng câu trả lời sẽ có lợi từ sự phân biệt giữa sai lầm, lỗi và lỗi (như tôi đã giải thích / định nghĩa chúng trong nhận xét của tôi về câu hỏi).
Raphael

Việc phân biệt các loại lỗi có thể hữu ích để chọn ngôn ngữ lập trình cho một dự án nhất định. Trong một số môi trường (ví dụ: hệ thống phê bình bảo mật), bạn muốn có càng nhiều lỗi càng tốt bởi trình biên dịch, để có thể loại trừ càng nhiều lỗi càng tốt. Cuối cùng, thậm chí có những trình biên dịch hiểu và xác minh các thông số kỹ thuật chính thức (đơn giản) (sẽ bắt được "các lỗi logic").
Raphael

1

Về cơ bản, bạn phải nhìn vào các ngôn ngữ đầu tiên.

PHP là ngôn ngữ thông dịch, có nghĩa là các tập lệnh được biên dịch và thực thi mỗi lần trong thời gian chạy C ++ là ngôn ngữ trình biên dịch, có nghĩa là các tập lệnh được biên dịch với trình biên dịch một lần khi xây dựng và sau đó có thể được thực thi.

vì vậy cả hai trình biên dịch đều nhận ra lỗi ngữ nghĩa từ ví dụ của bạn, nhưng trình biên dịch php thực hiện điều này trong thời gian chạy và trình biên dịch c ++ tại thời gian biên dịch.

Một lời giải thích tốt cho câu hỏi của bạn có thể được tìm thấy tại Wikipediaở đây (sự khác biệt giữa ngữ nghĩa và cú pháp)


Đây là sai lầm. Thông thường, PHP cũng được biên dịch và với bộ đệm opcode, pha biên dịch của nó được tách ra khỏi pha thực thi. Lý do thực sự cho sự khác biệt là C ++ sử dụng kiểm tra gõ và gõ mạnh hơn nhiều so với PHP. Cấp, gõ mạnh và biên dịch riêng biệt thường đi đôi với nhau, nhưng nói đúng ra họ không phải làm vậy.
rebierpost

0

Tôi đoán:

  • Một lỗi ngữ nghĩa (al) là một lỗi lập trình tạo ra mã có giá trị về mặt cú pháp, nhưng không thể thực hiện được những gì lập trình viên của nó dự định, bất kể ý định đó là gì. Mã này chắc chắn sai và có thể bị đánh dấu như vậy bởi các công cụ phần mềm - mặc dù các công cụ phần mềm không thể đánh dấu tất cả các lỗi như vậy (theo Định lý Rice).
  • Lỗi logic (al)lỗi lập trình tạo ra mã có giá trị cú pháp, nhưng không thực hiện được những gì lập trình viên dự định, mặc dù nó có thể đúng nếu lập trình viên có ý định khác. Mã chỉ sai khi có ý định của lập trình viên; công cụ phần mềm không thể gắn cờ mã là sai, điều tốt nhất họ có thể làm là gợi ý về khả năng xảy ra lỗi này.

0

Một chương trình là một văn bản nhằm thể hiện tính toán của một kết quả trả lời một câu hỏi về dữ liệu. Ví dụ, một chương trình sắp xếp sẽ lấy một danh sách các giá trị (dữ liệu) và sẽ tính toán một kết quả là một danh sách khác có cùng giá trị, nhưng được sắp xếp theo một số hàm so sánh.

Văn bản này phải được thể hiện chính thức bằng một loại ngôn ngữ được xác định chính xác (hoặc nên), cả về những gì tạo thành văn bản chương trình hợp pháp và làm thế nào một số ý nghĩa tính toán có thể được liên kết với văn bản này. Một định nghĩa chính xác như vậy thường trừu tượng (có thể là toán học) và có thể bỏ qua một số vấn đề cụ thể như giới hạn máy tính.

Nhưng sau đó, ngôn ngữ được thực hiện để các chương trình có thể được thực thi. Lại có nhiều cách để thực hiện như vậy, bằng cách sử dụng một intepreter của văn bản chương trình gốc hoặc biên dịch sang một số mã trung gian (ví dụ mã byte), sau đó có thể diễn giải mã intemediate này hoặc biên dịch thêm vào mã máy. Và có thể có các biến thể khác. Và tất nhiên, có nhiều cách viết trình biên dịch hoặc trình thông dịch, và nhiều máy để chạy chúng.

Hơn nữa, có thể có một số định nghĩa chính thức, và một số triển khai, hy vọng phù hợp.

Lỗi có thể được phân loại trong mối quan hệ cấu trúc của một hoặc cả hai định nghĩa chính thức hoặc / và việc thực hiện. Tuy nhiên, bạn có thể gặp các tình huống lạ khi các lỗi được phân loại theo cách triển khai tham chiếu cũ không còn được sử dụng.

Điều này về cơ bản có nghĩa là phân loại lỗi là một chủ đề không thực sự ổn định . Hơn nữa, một số ngôn ngữ có thể phân biệt một số mức độ lỗi tùy thuộc vào việc có gì đó chắc chắn sai (chương trình thậm chí sẽ không chạy) hoặc liệu bạn có đang làm điều gì đó không được khuyến nghị hay không, nhưng điều đó vẫn sẽ tạo ra một số tính toán, điều đó có thể có ý nghĩa. Điều này thậm chí còn được phản ánh trong các tính năng của các ngôn ngữ lập trình như ngoại lệ, có thể hoặc không thể được phục hồi.

Phân biệt tiêu chuẩn là:

Lỗi cú pháp : văn bản đã cho không phù hợp với cấu trúc của văn bản chương trình, độc lập với ý nghĩa của nó. Điều này chỉ có thể đề cập đến một cú pháp ngôn ngữ chính thức, thường là không có ngữ cảnh. Đôi khi nó có thể đi xa hơn và bao gồm việc kiểm tra một số tính năng cơ bản như khai báo biến (nếu có) hoặc tính nhất quán của loại, mặc dù những điều này cũng có thể được coi là lỗi ngữ nghĩa.

Lỗi ngữ nghĩa hoặc logic : đây là những lỗi có thể được phát hiện khi thực sự chạy chương trình do thực tế là chương trình chạy vào một phép tính không có ý nghĩa ngữ nghĩa, chẳng hạn như chia cho 0 hoặc lập chỉ mục một mảng ngoài giới hạn. Gọi một hàm với số lượng đối số sai hoặc với các đối số sai loại cũng có thể được coi là một lỗi ngữ nghĩa. Trong một số ngôn ngữ, lỗi thực sự có thể được xác định bởi người dùng bằng các ngoại lệ, khi chúng tương ứng với một số ngữ nghĩa cấp cao hơn do người dùng xác định cho một phần của chương trình của mình (mặc dù có các cách sử dụng ngoại lệ khác). Một số lỗi này đôi khi cũng được gọi là lỗi thời gian chạy vì chúng được phát hiện trong thời gian chạy, nhưng chúng không nên bị nhầm lẫn với các lỗi giới hạn phần cứng.

Lỗi giới hạn phần cứng : đây là những lỗi do thực tế là việc triển khai trên một máy thật có những hạn chế. Ví dụ, đây có thể là một số nguyên quá lớn để phù hợp với một từ bộ nhớ hoặc thiếu bộ nhớ đủ để tạo cấu trúc dữ liệu. Chúng cũng thường được phát hiện trong thời gian chạy.

Liên quan đến lỗi ngữ nghĩa và lỗi giới hạn phần cứng, đôi khi có thể phát hiện ra chúng trước khi thực hiện chương trình, với cái được gọi là phân tích ngữ nghĩa tĩnh. Đây thường là trường hợp cho các khai báo hoặc các biến chưa được khởi tạo, hoặc cho các lỗi loại hoặc để chia cho 0 và một số kiểm tra ràng buộc mảng, nhưng nó có thể đi xa hơn nhiều. Phân tích ngữ nghĩa tĩnh cũng rất quan trọng trong trình biên dịch cho nhiều kỹ thuật tối ưu hóa. Thường có một sự tách biệt giữa ngữ nghĩa tĩnh và động. Định nghĩa tốt nhất tôi có thể tưởng tượng là ngữ nghĩa tĩnh liên quan đến các thuộc tính có thể quyết định tại thời điểm biên dịch, không có dữ liệu thực tế. Vì vậy, chia cho số 0 sẽ không phải là một phần của ngữ nghĩa tĩnh nói chung. Điều này nói lên rằng một số lỗi ngữ nghĩa động đôi khi vẫn có thể được phát hiện tại thời điểm biên dịch. Điều tương tự cũng xảy ra đối với các lỗi giới hạn phần cứng.

Nhưng mọi nhà thiết kế ngôn ngữ hoặc người thực hiện đều có quyền phân loại lỗi theo ý muốn , trừ khi bị ràng buộc bởi hợp đồng hoặc giấy phép. Đó cũng có thể là trường hợp cho ví dụ PHP của bạn. Và bất cứ ai cũng có thể phân biệt giữa các lỗi ngữ nghĩa và logic, mặc dù tôi sẽ không biết cách xác định sự khác biệt, trừ khi có thể được nói chi tiết về các lỗi này. Người ta có thể được sử dụng để biểu thị lỗi trong ý định (lỗi logic) và hệ thống sẽ không thể phát hiện được.

Lưu ý rằng có thể có các loại lỗi khác trong một chương trình , thường sẽ không được hệ thống phát hiện. Điều đó bao gồm sự không nhất quán cụ thể của chương trình với đặc điểm kỹ thuật của nó (hoặc cái mà tôi gọi là lỗi trong ý định: người dùng không làm những gì anh ta muốn làm), hoặc có thể lỗi trong chính đặc tả. Cũng có thể có lỗi do giới hạn phần cứng, chẳng hạn như lỗi làm tròn khi làm việc với số thực.


-2

Theo ghi chú khóa học máy tính cao hơn của tôi, lỗi ngữ nghĩa và lỗi logic chỉ là những tên khác nhau cho cùng một thứ.


1
Lỗi ngữ nghĩa khác với lỗi logic.
Juho

1
Thật không may, điều này không hữu ích. Bạn không đồng ý với các câu trả lời khác nhưng lời giải thích duy nhất bạn đưa ra là kháng cáo lên chính quyền ("Giáo viên của tôi nói vậy!").
David Richerby
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.