2 ms·

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

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).
panzi 3y ago
I too learned that terminology at university almost 20 years ago. Haven't heard it used like that since. Yes, precise language would be useful for communication, but in this case it feels like a lost cause. Nobody uses these terms like that.
- nordsieck 3y ago
  > Nobody uses these terms like that. Yeah - it feels a bit like "Mebibyte". Sure, it's technically the correct name of a base-2 Megabyte. But people just use "Megabyte" and use context to figure out if people mean base-10 or base-2.
  - f1shy 3y ago
    The problem is that people writing norms are (typically) people without any contact with reality. In theory they are great. No place in practice. Best example iso stack vs. Tcp/ip
  - kiitos 3y ago
    Mebibyte is well defined. Error is not.
    - Nevermark 3y ago
      But as pointed out, “Megabyte” is not clearly defined in informal usage. Informally, it has two specific meanings, and a third useful fuzzy meaning when the distinction between 10^6 and 2^20 does not matter.
  - samatman 3y ago
    My unprincipled compromise is that I spell it MiB and pronounce it 'megabyte'. Spoken language is lousy with ambiguity already, I can't recall a time when I've ever had to clarify which I meant in conversation.
kiitos 3y ago
If you try to assert a specific definition of a specific term like "HTTP error 503" then you have some authority. But if you try to assert a specific definition of a generic term like "error" then you don't really have the same authority, and you can't be surprised when other systems don't follow your definitions.

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).

panzi 3y ago

I too learned that terminology at university almost 20 years ago. Haven't heard it used like that since. Yes, precise language would be useful for communication, but in this case it feels like a lost cause. Nobody uses these terms like that.

nordsieck 3y ago
> Nobody uses these terms like that. Yeah - it feels a bit like "Mebibyte". Sure, it's technically the correct name of a base-2 Megabyte. But people just use "Megabyte" and use context to figure out if people mean base-10 or base-2.
- f1shy 3y ago
  The problem is that people writing norms are (typically) people without any contact with reality. In theory they are great. No place in practice. Best example iso stack vs. Tcp/ip
- kiitos 3y ago
  Mebibyte is well defined. Error is not.
  - Nevermark 3y ago
    But as pointed out, “Megabyte” is not clearly defined in informal usage. Informally, it has two specific meanings, and a third useful fuzzy meaning when the distinction between 10^6 and 2^20 does not matter.
- samatman 3y ago
  My unprincipled compromise is that I spell it MiB and pronounce it 'megabyte'. Spoken language is lousy with ambiguity already, I can't recall a time when I've ever had to clarify which I meant in conversation.

kiitos 3y ago

If you try to assert a specific definition of a specific term like "HTTP error 503" then you have some authority. But if you try to assert a specific definition of a generic term like "error" then you don't really have the same authority, and you can't be surprised when other systems don't follow your definitions.