What exactly is wrong with it? That is a definition fit for someone who does not have prior knowledge of what a runtime error is. It might be boring to us, and I might word it a little different, but it's fine.
For me it's the last sentence: "Once identified, runtime errors are easy to fix." Well no not really - it depends on the issue; sometimes a solution isn't 'fixing' it, sometimes choosing what to do next after identifying the root cause is it's own task. Maybe it's working around it, like amending the return value with amended data, or patching the API itself by wrapping it in an intermediate API and swallowing exceptions. Guidance on addressing runtime errors should never presuppose that 'fixing' it will be easy - it will always depend on the context. Just get rid of that last sentence and it's a better statement.
Imagine instead it's for criminal defense lawyers: re-word it to be advice for attorneys defending their client against a prosecution. "Once [all exculpatory evidence against your client] is identified, defending them against a guilty verdict is easy to do"
It sounds like it's written by someone who has never practiced in the real world.
I think it should say runtime errors "are usually easy to fix" because they are usually a result of simple logical errors or technical issues. But you're right, it does not account for all possibilities.
> Runtime errors surface when a program runs into an unexpected condition or situation such as dividing by zero,
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. Dividing by zero is very frequently not unexpected (it's utterly commonplace in 3-D graphics, for example, when a vertex happens to be in the camera's focal plane) and in floating-point math (standardized by, ironically, the IEEE) it doesn't generate runtime errors by default. Moreover, there are certain applications where runtime errors are also expected, such as in fuzzers. Some languages frequently use their runtime error mechanism to convey perfectly mundane conditions such as not finding a key in a hash table or coming to the end of a sequence. And it's fairly often a useful mechanism for terminating a recursive search procedure.
> memory overflow,
There's no such thing as a "memory overflow" on any platform I'm familiar with. This might have been intended to reference any of five things: stack overflows, buffer overflows, heap allocation failures, resource limit exhaustion, or OOM kills.
The stack is an area of memory, and a "stack overflow" is an attempt to put too much data in it, usually due to an infinite recursive loop. Stack overflows do often get detected as runtime errors, but many platforms fail to detect them, causing incorrect program behavior instead.
A buffer is also an area of memory (an array) and a "buffer overflow" is an attempt to put too much data in it, usually due to an omitted check on input data size. Buffer overflows do sometimes get detected as runtime errors, but often do not, because the most popular implementations of many popular programming languages (notably C, C++, and Pascal) do not do automatic bounds checking.
Heap allocation failures are attempts to dynamically allocate memory that are denied, often because too much memory is already allocated, so in a sense your heap memory has "overflowed". Some programming languages handle this as a runtime error, but the most popular implementations of many popular programming languages (notably C, C++, and Pascal) do not.
Resource limit exhaustion is a condition where a program exceeds operating-system-imposed limits on its usage of resources such as CPU time, output file size, or memory usage, in response to which the OS raises a runtime error. On Unix this manifests as killing the process with a signal.
OOM kills are a Linux thing where the OS starts killing resource-intensive processes to attempt to recover from a memory overload condition that is degrading service badly. In a sense the computer's memory has "overflowed", so Unix's runtime error mechanism is pressed into service. (Something very similar happens if you press ^C, though, so describing this as a "runtime error" is maybe not defensible.)
> or addressing a wrong or unauthorized memory location or device,
The standard verb here would be "accessing", not "addressing", but I don't want to make too much of the use of nonstandard terminology; it's not always an indicator of unfamiliarity with the field. And there are indeed machines where there are kinds of "wrong" other than "unauthorized"—that's why we have SIGBUS, for unaligned access exceptions on CPUs that don't support unaligned access.
But "device" is, as far as I know, wrong; I don't know of any platform which raises a runtime error when you try to access the wrong device. There are a number of platforms that have I/O instructions which will raise a runtime error if you try to use them in unprivileged code, but that doesn't depend on which device you're accessing. Usually in small microcontrollers there isn't any kind of runtime-error mechanism, and when there is, it generally isn't invoked for I/O instructions. Sometimes you can set up the MPU so that certain code can't access devices—when they're memory-mapped, in which case "memory location" would have covered the case.
Even if there is some platform where it's possible to get a runtime error accessing the wrong device, it's far from the kind of common case you'd want to include in such an abbreviated list of typical causes of runtime errors "for someone who does not have prior knowledge of what a runtime error is". Much more typical would be illegal instructions, attempts to access privileged state from unprivileged code, null pointer dereferences, runtime type errors such as ClassCastException, and array bounds violations, none of which are mentioned.
It seems like someone who doesn't know anything about software was trying to imagine what kinds of things might, in theory, cause runtime errors, but the kinds of protection mechanisms they imagined were completely different from the ones used in actual existing computers.
> or when a program tries to perform an illegitimate or unauthorized operation
As a simple matter of logic, this subsumes the previous item, and "illegitimate" in this context means the same thing as "unauthorized". So this list is not just comprehensively wrong at a technical level, but also so badly written as to be incoherent.
> or tries to access a library, for example.
This is completely wrong. Of course a program can get a runtime error when it tries to load a library, just as it can get a runtime error when it undertakes any other task, but there is no platform that raises a runtime error whenever you try to access a library.
> The programs must be thoroughly tested for various types of inputs (valid data sets, invalid data sets and boundary value data sets) and conditions to identify these errors.
This statement, in itself, only contains a couple of slight factual errors.
First, it says that the inputs to programs are data sets. This is probably something that someone who doesn't know anything about software copied from a 60-year-old textbook, because at that time, the inputs to programs were data sets (now more commonly known as files). In fact, the more important inputs to programs nowadays are things such as user interactions, data received over a network, and data received in real time from sensors such as microphones, oxygen sensors, and accelerometers. But this statement is stuck in punched-card land, where programs punched into card decks ran in batch mode to process some input data sets and produce some output data sets.
The second factual error is that it implies that runtime errors result primarily from inputs and how the program responds to them. And, of course, there are runtime errors that are determined by the program's handling of inputs; typically type errors, null pointer exceptions, array bounds violations, etc., can be reproduced if you run the program again with the same input. But large classes of runtime errors do not fit this profile. Some are errors that depend on internal nondeterminism in the program, such as nondeterministic interactions between different threads (we would say "scheduler interleaving order" back in the single-core days), or nondeterministic timing. Others depend on runtime conditions like how much memory is available to allocate or how full the disk is (writing to a full disk in Python raises an exception, though not in many other languages). Others result from hardware problems such as overheating. The statement does, in passing, say "and conditions", but these are given short shrift.
The much bigger problem with this statement, though, is that it's in the middle of a paragraph about runtime errors. But everything it says is equally applicable to logic errors, the subject of the next paragraph; indeed, much of it is more applicable to logic errors. Putting it in the middle of this paragraph misleadingly implies that things like testing with invalid input files (or the other, more important, invalid inputs it failed to mention) are uniquely or primarily applicable to runtime errors.
> Once identified, runtime errors are easy to fix.
This statement is also wrong in a multidimensional way.
First, although this is in the "debugging" section, many runtime errors aren't bugs at all. A program crashing with a MemoryError or OutOfMemoryError when it is run with insufficient memory available to allocate is, in general, desired behavior. It's also often the desired behavior when it's applied to a too-large input, though obviously that's not acceptable for games or avionics software. The same is true of permission errors, out-of-disk-space errors, etc. These are specifically the kind of runtime errors that most commonly result from the "and conditions" in the previous sentence.
Second, while it's usually easier to debug a segfault or exception than silently incorrect output, it is often far from trivial to track down the runtime error to its ultimate cause.
Third, even when you have figured out what the ultimate cause is, fixing it is sometimes not easy, for example because other people's deployed software depends on interfaces you have to change, or more generally because it is difficult to understand what other problems could be caused by the possible fixes you are considering.
By my count, that's 12 significant factual errors in 86 words, an average of 7.2 words per error. This is an error density that would be impressive in any contexts, although I've occasionally seen expert liars exceed it somewhat. In the context of an official publication purporting to establish standards for professional competence, it's utterly horrifying.
So this is not a definition fit for anyone, least of all someone who does not have prior knowledge of what a runtime error is; it is very far from being fine. It's embarrassing horseshit.
And it's not just this one paragraph. Virtually the entire document is like this. Occasionally you'll find a paragraph that's mostly correct from beginning to end, but then it'll be followed by the cringiest idiocy you can possibly imagine in the very next paragraph.
With respect to this paragraph in particular, an even worse problem than its unreliability is emphasis. This is from §4.6, "Debugging", which is 189 words, about a quarter of p. 16-13 (p. 326/413). Debugging is arguably the central activity of software engineering; about a quarter of the effort† spent on software engineering is spent on debugging, an amount which would be larger if we didn't spend so much effort on avoiding debugging (for example, with type systems, unit tests, version control, and documentation). Any actual software engineering body of knowledge would be largely concerned with knowledge about debugging. But the IEEE relegates it to 0.2% of their document.
Crikey. Nitpicking a single sentence (in a document of hundreds of pages) to the degree you just did is not nearly useful as you seem to think.
Sometimes a sentence is a little too general, or too specific. It happens often and we all know that. Indeed, in this short post I've probably already committed that sin. 100% guaranteed you made several errors (especially of degree) in the post above.
There's an enormous difference between "sometimes a sentence is a little too general, or too specific" and making 12 serious factual errors in 86 words. My comment is 1944 words, at least according to Emacs; if it had the same error density, it would have not just several errors (though I note you were unable to find any!) but 271 serious ones.
You did make one error in your comment, though; when you said "Nitpicking a single sentence", you implied that my comment only dissected the errors in a single sentence, rather than an entire paragraph.
When text is carefully drafted by competent people, it is impossible to "nitpick" it to the degree I just did. It is very rare to find something either as error-filled or as badly written as this paragraph. The fact that the document is hundreds of pages long makes the situation far worse, not better; all of those hundreds of pages seem to be of the same appalling quality.
What, you think I wrote the SWEBOK? Or maybe you just don't understand the Shakespeare you're quoting any more than you understood what I was saying in the first place.
In https://news.ycombinator.com/item?id=41918401 you admit that you only skimmed my comment; that's why you mistook it for nitpicking. Consequently, your response is wholly incorrect.
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
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.
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.
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.)
>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.
