8 ms·

Not my definition, the IEEE Standard Glossary of Software Engineering Terminology definition. Yes the title is clickbait (I mention that's intentional in the po

Not my definition, the IEEE Standard Glossary of Software Engineering Terminology definition. Yes the title is clickbait (I mention that's intentional in the post) because people keep mixing up faults and failures, be it i.e. Elm's approach (all in on faults) vs Erlang's approach (all in on failures). Without properly defined terminology understanding the difference in focus leads to unproductive discussion. EDIT: In your defense the later standards appear to have made "error" a uselessly wishy-washy term again, so eh. The terms fault/error/failure as defined in the post are still used in the study of fault tolerance.

deleted 3y ago
[deleted]
Groxx 3y ago
The fact that a standard exists somewhere for something doesn't mean that it's an accepted-in-practice usage. Or even vaguely imply. You probably don't have a jar of SRM 2387 peanut butter on your shelf, for instance. The three-term separation makes plenty of sense and when I see all three together in a doc it's generally clear that they mean something along those lines, but it's far from normal use. --- Late edit: to make this perhaps a bit more useful / constructive: because of ^ this, it's being perceived as a clickbait title. And perception is all that matters in "is this title clickbait", because it's what determines the level of interaction someone is willing to pay at the beginning. Clickbait-title leads to clickbait-pushback. You don't have to change it of course, and it fits with the post's narrative, but I can pretty much guarantee that it'll keep causing this kind of reaction in some (many? few? idk) people.
- sirwhinesalot 3y ago
  Fair enough, I was taught the terminology in university on a course on fault tolerance. Personally I wish their usage was more standardized, in fact if it was I wouldn't have had to explicitly mention they're taken from IEEE 610.12-1990 and that I'm using them to split "error" into 3 separate but related ideas for clarity. Either I made it clear in the post I didn't make up the terms so no idea what the original commenter is on about.
  - Groxx 3y ago
    Yeah, it's not a totally unknown standard or anything. But I feel pretty safe claiming that "bug" (unobserved in code) / "error" (handled in code) / "crash/fatal/unhandled error" (obvious) is both far more common and far clearer at a glance... which is probably why it's more common. In technical documents, the standard can be useful for being very explicit and unambiguously identifiable. I'm far from convinced that it deserves use elsewhere tho.
    - sirwhinesalot 3y ago
      I'm replying to you Groxx but hopefully panzi will also see it. I definitely see where both of you are coming from. The issue (I feel) is that if I were to do as you suggest, and just use 3 commonly used but not agreed upon terms (bug, error, crash), then the original comment of this thread would be justified in their criticism (that I'm making up my own definitions for clickbait). I actually had to present my own definitions for terms in my article about OOP, so I could explain why I like objects but not OOP, because the terminology in practice is so diluted to be next to useless :(
      - edderly 3y ago
        If it helps I think you're right to take this approach. In my experience defining error as 'handled' or handleable in code can often not be particularly helpful. Are the values from errno(3) always considered as handled? EINVAL is almost always in "your" terms a fault, ENOSPC or EPIPE likely could only be handled as complete failures. What I see too often is code which which propagates
        Groxx 3y ago
        I might push for a different set of divisions there tbh. errno(3) is handle-able because the information exists and it is possible to use. It's the same as any other "a problem occured" signaling mechanism in that sense. Its main sin is being out-of-band of the trigger, so it's extremely easy to forget. Whether it is handled (checked) in code is a subdivision of handle-able. Some signaling mechanisms are better about preventing not-handled than others, depending on context. Whether you can recover from it (do something else, try again until success, etc) is also a subdivision of handle-able, and is completely unrelated to whether it was handled or not. And I think I can claim that in literally all cases the "recover-ability" is also completely unrelated to the kind of problem (ENOSPC vs EINVAL) - it only depends on what you are trying to do right now, which depends on the rest of the program and the user intent. If it was inherently unrecoverable, it wouldn't be errno(3), it'd just never return (e.g. kill your process, infinite loop, etc). Under that framework, ENOSPC is just a normal handle-able error. It's frequently a fatal failure that is easy to forget, but it's easy to come up with something that expects and recovers from it, e.g. a lossy caching tool. Similarly, EINVAL is an unrecoverable error if you are a tool that fails on bad input, like a compiler, despite being easily recoverable in some cases (probing for feature support and gracefully degrading, perhaps).
f1shy 3y ago
I hate engineers playing lawyer, and also I do not know the IEEE definition, but acording to ISO26262 your definition is wrong: fault is undetected, error detected (but may or maynot be handled by for example resundancy) and an unhandled error that results in deviation of req. sys. behaviour is a failure. Also note: fault can be a bug in SW, but an unexpected behaviour of the HW
- sirwhinesalot 3y ago
  It's not playing lawyer, it's agreeing upon some terminology for the purpose of discussion. I was accused of making up terms, I didn't, I used existing terms from one particular standard. The very reason I used existing terms from a standard was to avoid the very accusation I got anyway in this hackernews thread, but that's the internet for you. I even mention in the article that the term fault is used differently in the context of hardware faults, different standards have different meanings for the same terms, which is why I also lay them out and don't expect you to know the standard in the article.
nyrikki 3y ago
Efforts like the "IEEE Standard Glossary of Software Engineering Terminology", where from an era that we learned what didn't work, which linguistics had learned way before CS. The IEEE didn't go 'wishy-washy' they accepted that at that scope, 'Descriptive' was the appropriate approach and 'Prescriptive' was inappropriate for a broad context. Same thing happen with most English dictionaries. https://www.merriam-webster.com/grammar/descriptive-vs-prescriptive-defining-lexicography https://www.merriam-webster.com/grammar/descriptive-vs-presc... “Ubiquitous Language” concepts from DDD is probably the best example here. Domain specific language is always polysemous to a wider scope. So DDD typically defaults to allowing domain experts (think accountants, not accounting software developers) to object to a rigorous “Ubiquitous Language” for interfacing with each other. This is important because when domain experts object to a formal definition as proposed, they are possibly concerned about nuances in that language that are important. Obviously they may just be pedantic, but the default assumption is that they are trying to convey something important about the domain of discourse. The Prescriptive model of enterprise architecture utterly failed to live up to it's promise, in part because word sense ambiguity is a pervasive characteristic of natural language even at the scope of an enterprise.
- sirwhinesalot 3y ago
  Fair comments, I wasn't hoping to use the IEEE standard as an appeal to authority, just clarifying I didn't make up the terms. Sadly as you say, these formal definitions don't end up agreed upon, which is why it is always important to clarify what you mean when you use a certain word (which I hopefully did in the post).
potamic 3y ago
I also felt the same as loeg after finishing the article. If you simply state that invalid states cannot be handled, I believe most people here would concur. And in the end, I do think that this is a very significant insight that you describe. But using a narrow definition of errors to mean invalid state disregards any prior literature and programming manuals that already talk in terms of "error handling" and asks readers to suspend all of that while reading the article.

deleted 3y ago

[deleted]

Groxx 3y ago

The fact that a standard exists somewhere for something doesn't mean that it's an accepted-in-practice usage. Or even vaguely imply. You probably don't have a jar of SRM 2387 peanut butter on your shelf, for instance. The three-term separation makes plenty of sense and when I see all three together in a doc it's generally clear that they mean something along those lines, but it's far from normal use. --- Late edit: to make this perhaps a bit more useful / constructive: because of ^ this, it's being perceived as a clickbait title. And perception is all that matters in "is this title clickbait", because it's what determines the level of interaction someone is willing to pay at the beginning. Clickbait-title leads to clickbait-pushback. You don't have to change it of course, and it fits with the post's narrative, but I can pretty much guarantee that it'll keep causing this kind of reaction in some (many? few? idk) people.

sirwhinesalot 3y ago
Fair enough, I was taught the terminology in university on a course on fault tolerance. Personally I wish their usage was more standardized, in fact if it was I wouldn't have had to explicitly mention they're taken from IEEE 610.12-1990 and that I'm using them to split "error" into 3 separate but related ideas for clarity. Either I made it clear in the post I didn't make up the terms so no idea what the original commenter is on about.
- Groxx 3y ago
  Yeah, it's not a totally unknown standard or anything. But I feel pretty safe claiming that "bug" (unobserved in code) / "error" (handled in code) / "crash/fatal/unhandled error" (obvious) is both far more common and far clearer at a glance... which is probably why it's more common. In technical documents, the standard can be useful for being very explicit and unambiguously identifiable. I'm far from convinced that it deserves use elsewhere tho.
  - sirwhinesalot 3y ago
    I'm replying to you Groxx but hopefully panzi will also see it. I definitely see where both of you are coming from. The issue (I feel) is that if I were to do as you suggest, and just use 3 commonly used but not agreed upon terms (bug, error, crash), then the original comment of this thread would be justified in their criticism (that I'm making up my own definitions for clickbait). I actually had to present my own definitions for terms in my article about OOP, so I could explain why I like objects but not OOP, because the terminology in practice is so diluted to be next to useless :(
    - edderly 3y ago
      If it helps I think you're right to take this approach. In my experience defining error as 'handled' or handleable in code can often not be particularly helpful. Are the values from errno(3) always considered as handled? EINVAL is almost always in "your" terms a fault, ENOSPC or EPIPE likely could only be handled as complete failures. What I see too often is code which which propagates
      - Groxx 3y ago
        I might push for a different set of divisions there tbh. errno(3) is handle-able because the information exists and it is possible to use. It's the same as any other "a problem occured" signaling mechanism in that sense. Its main sin is being out-of-band of the trigger, so it's extremely easy to forget. Whether it is handled (checked) in code is a subdivision of handle-able. Some signaling mechanisms are better about preventing not-handled than others, depending on context. Whether you can recover from it (do something else, try again until success, etc) is also a subdivision of handle-able, and is completely unrelated to whether it was handled or not. And I think I can claim that in literally all cases the "recover-ability" is also completely unrelated to the kind of problem (ENOSPC vs EINVAL) - it only depends on what you are trying to do right now, which depends on the rest of the program and the user intent. If it was inherently unrecoverable, it wouldn't be errno(3), it'd just never return (e.g. kill your process, infinite loop, etc). Under that framework, ENOSPC is just a normal handle-able error. It's frequently a fatal failure that is easy to forget, but it's easy to come up with something that expects and recovers from it, e.g. a lossy caching tool. Similarly, EINVAL is an unrecoverable error if you are a tool that fails on bad input, like a compiler, despite being easily recoverable in some cases (probing for feature support and gracefully degrading, perhaps).

f1shy 3y ago

I hate engineers playing lawyer, and also I do not know the IEEE definition, but acording to ISO26262 your definition is wrong: fault is undetected, error detected (but may or maynot be handled by for example resundancy) and an unhandled error that results in deviation of req. sys. behaviour is a failure. Also note: fault can be a bug in SW, but an unexpected behaviour of the HW

sirwhinesalot 3y ago
It's not playing lawyer, it's agreeing upon some terminology for the purpose of discussion. I was accused of making up terms, I didn't, I used existing terms from one particular standard. The very reason I used existing terms from a standard was to avoid the very accusation I got anyway in this hackernews thread, but that's the internet for you. I even mention in the article that the term fault is used differently in the context of hardware faults, different standards have different meanings for the same terms, which is why I also lay them out and don't expect you to know the standard in the article.

nyrikki 3y ago

Efforts like the "IEEE Standard Glossary of Software Engineering Terminology", where from an era that we learned what didn't work, which linguistics had learned way before CS. The IEEE didn't go 'wishy-washy' they accepted that at that scope, 'Descriptive' was the appropriate approach and 'Prescriptive' was inappropriate for a broad context. Same thing happen with most English dictionaries. https://www.merriam-webster.com/grammar/descriptive-vs-prescriptive-defining-lexicography https://www.merriam-webster.com/grammar/descriptive-vs-presc... “Ubiquitous Language” concepts from DDD is probably the best example here. Domain specific language is always polysemous to a wider scope. So DDD typically defaults to allowing domain experts (think accountants, not accounting software developers) to object to a rigorous “Ubiquitous Language” for interfacing with each other. This is important because when domain experts object to a formal definition as proposed, they are possibly concerned about nuances in that language that are important. Obviously they may just be pedantic, but the default assumption is that they are trying to convey something important about the domain of discourse. The Prescriptive model of enterprise architecture utterly failed to live up to it's promise, in part because word sense ambiguity is a pervasive characteristic of natural language even at the scope of an enterprise.

sirwhinesalot 3y ago
Fair comments, I wasn't hoping to use the IEEE standard as an appeal to authority, just clarifying I didn't make up the terms. Sadly as you say, these formal definitions don't end up agreed upon, which is why it is always important to clarify what you mean when you use a certain word (which I hopefully did in the post).

potamic 3y ago

I also felt the same as loeg after finishing the article. If you simply state that invalid states cannot be handled, I believe most people here would concur. And in the end, I do think that this is a very significant insight that you describe. But using a narrow definition of errors to mean invalid state disregards any prior literature and programming manuals that already talk in terms of "error handling" and asks readers to suspend all of that while reading the article.