[wakawaka28]

You're reading WAY too much into it. Sometimes things are meant to be simplified, and this is one of those cases. We are essentially talking about a brief description of something in a textbook.

>This implicitly asserts that dividing by zero is always unexpected, that all runtime errors are unexpected, and that dividing by zero always causes a runtime error. None of these are true.

You are assuming basically all of that stuff. Dividing by zero is almost always an error, is usually unexpected, and is a suitable example of a runtime error. Just because it may not be unexpected sometimes does not make it an unsuitable example. If I said "Taxable events surface when a person conducts a taxable transaction such as sale of goods or labor" does not in any way imply that all sales of goods or labor are taxable. It is implied in the sentence that the examples refer to common errors.

If you talked to 100 programmers and asked them to give an example of a common runtime error, I think conservatively at least 95 of them would spit out "division by zero" or "stack overflow". The audience of this book may conceivably not know what a stack is yet, so "memory overflow" conveys that you have used more memory than expected.

I don't have enough patience right now to shred the rest of your "analysis" but I can tell that you're the type of person who used to get pissed off at textbooks in school because they never mention air resistance. You probably got pissed off at that sentence because you once saw a textbook that did say "ignore air resistance" lol

[kragen]

Well, you asked what was wrong with it, and I answered. If you don't bother to read the answer to the question you asked, that's on you.

I do agree that a division-by-zero exception is a good example of a runtime error, and—as I said in the comment you are purportedly responding to!—that the examples are intended to refer to common errors. (However, most of them fail to do so, evidently due to the ignorance of the authors.)

I would get pissed off at physics textbooks that said air resistance didn't exist, but I haven't ever seen such a bad physics textbook—and I've seen some pretty bad physics textbooks!

The rest of your comment is completely incorrect, and the personal attacks in your comment do not rise to the level of discourse desired on this site. It seems like you missed the main points of my comment, in several cases responding to my reasoned arguments with simple contradiction, and are unaware of the intended audiences of the SWEBOK.

Simplification is not only fine but a sine qua non for high-level summaries of a field. And simplifications are always in some sense erroneous. But the objective of simplification in a summary is to lead the reader toward the truth, even if you can't quite reach it—you can formulate the ballistics ODEs including air resistance much more easily once you've learned to handle the simplified version without. However, when someone doesn't understand the field, they often produce a "simplification" that includes lots of incorrect unnecessary detail and which is broadly misleading, and that is what happened in this case, as I explained in detail in my comment above. Someone who knew nothing about runtime errors would know less than nothing about them after reading that "simplification".

And the document goes on for hundreds of pages at this atrocious quality level.

[wakawaka28]

I didn't miss anything you said. I did read your comments and frankly I don't have the time to address the level of banality therein. My position is that you are erecting and burning an elaborate straw man based on the least reasonable reading of a general statement, and you don't understand who the audience is. If someone has to be told what a runtime error is, that means they don't necessarily know it. That definition is totally adequate for the purpose of conveying the concept.

You accuse me of being personal but your comments are some of the most pompous crap I've read in ages.

>And the document goes on for hundreds of pages at this atrocious quality level.

Oh so you read the whole thing? Lol

[kragen]

It sounds like you aren't very clear on what a "runtime error" is yourself, or what role they play in software development, which I guess is why you didn't see anything wrong with the ostensible definition in the SWEBOK. You could probably learn a lot from reading my longer comment carefully enough to understand it.

The audience of the SWEBOK is not only, or even primarily, learners. This is explained in the preface.

Thinking my comments are pompous—because they're written in a more formal register than you're accustomed to reading, I suppose—is no excuse for your invective.

I didn't read the whole document, but, as you can see from https://news.ycombinator.com/item?id=41916612, I did generate a fair random sample of 10 half-pages of it and read and summarize them. All of them were similarly incoherent and full of serious errors of fact that can only be attributed to profound incompetence. That's an adequate basis on which to conclude that the whole thing is bad. Moreover, everyone else in this thread commenting on specific parts of the document that they've read has similarly damning comments. (Except you, but at this point I have, I think, ample reason to discount your opinion.)

[wakawaka28]

>It sounds like you aren't very clear on what a "runtime error" is yourself, or what role they play in software development, which I guess is why you didn't see anything wrong with the ostensible definition in the SWEBOK.

Of course I know exactly what a runtime error is. The definition we're talking about is fit for purpose.

>The audience of the SWEBOK is not only, or even primarily, learners. This is explained in the preface.

OK fine. But you do in fact have to learn it for the purpose of getting an engineering license. It would be inappropriate to load the document with details that are not relevant to nearly all programmers, or details that are couched in such formal language that they would be inaccessible to average engineers with 4 year degrees. Nothing in your comment is that advanced but certainly a PhD-level lawyer take on what constitutes a runtime error is beyond the scope of what the document is for, despite the ambitious name.

>Thinking my comments are pompous—because they're written in a more formal register than you're accustomed to reading, I suppose—is no excuse for your invective.

The issue is not that your comments are formal, but that you think nobody but you knows what a runtime error is. When people tell you that they do in fact know what it is and that the definition offered is adequate, you insist on practically writing a stuffy paper about why you think it doesn't cover this or that.

>All of them were similarly incoherent and full of serious errors of fact that can only be attributed to profound incompetence.

This is pompous. I don't care to read more of your nonsense. Frankly, the notion that someone would get to be the guy (or committee) who would write a textbook like this for a licensing body without having ample competence in the field (as opposed to "profound incompetence") is so outlandish that I cannot take it seriously. That applies doubly to your opinion, which has been pathologically pedantic.

>Moreover, everyone else in this thread commenting on specific parts of the document that they've read has similarly damning comments.

I'm not talking about the rest of the document. Most of the comments I read on here are pure garbage so appealing to plurality is not getting you anywhere.

>Except you, but at this point I have, I think, ample reason to discount your opinion.

Be honest, you never took my opinion seriously. After your first comment I had ample reason to discount your opinion too. My instinctive reaction is to assume you have some kind of mental disorder that makes you overanalyze things. But maybe you are just a snob. It's hard to diagnose this over the Internet, and I don't really care.

[kragen]

Whatever.