Hacker News Reader

Comment by Groxx | Hacker News Reader

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.

View on HN

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.

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.

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 :(

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

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

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.

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

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

Mebibyte is well defined. Error is not.

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.

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.

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.

Reply on news.ycombinator.com