Software Engineering Body of Knowledge (SWEBOK) v4.0 is out [pdf]

  Runtime errors surface when a program
  runs into an unexpected condition or situation
  such as dividing by zero, memory overflow, or
  addressing a wrong or unauthorized memory
  location or device, or when a program tries to
  perform an illegitimate or unauthorized operation
  or tries to access a library, for example.
  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. Once identified,
  runtime errors are easy to fix.

Embarrassing horseshit.

> or tries to access a library

I had to open the PDF and find this line to confirm. It really says that. It reads as if claiming that any program that accesses a library will then have a runtime error. That is obviously not what they intended, but I have read it over a few times now and cannot see another interpretation.

That line is referring to shared libraries linked to a dynamic executable. If a shared library isn't installed or available you will receive an error similar to the following:

    $ ./main
    ./main: error while loading shared libraries: librandom.so: cannot open shared object file: No such file or directory 

Which is indeed a runtime error.

There is also the common use case of hot-reloading compiled code which dynamically loads and unloads shared libraries without restarting the entire application. It needs to be done carefully but you've likely used an application that does this. Failure to load a library, or loading an incompatible one will also create a runtime error.

Looks like there is a lot of bad generalizations in here, but they are technically correct on this one.

I understand that is what they meant, but it is not what they wrote. They should have qualified the statement as you did, with the conditions that yield a runtime error. Even if they generalized those conditions that would have been fine.

for example:

  or tries to access a library that it is unable to for some reason without handling the resulting error.

Perhaps if they said "tries and fails to access a library". Merely attempting to access (possibly successfully) a library is not an error.

I suppose, yeah, when I figure out the exact reason why the error occurred, fixing it is often easy. The finding, however, can often take a long time, which leaves me feeling "once you have driven across the continent, finding your desired endpoint is a quick process". "Once constructed, installing the door on your new house is a simple and easy task". Well, sure, if you take out the time-consuming parts, it's quick and easy.

Except for all those runtime errors where the fix required major refactoring, or the problem is in a third party library, the OS, or some other unchangeable component.

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.

Ah, but the existence of a suitable library in the environment is assumed. So not having it is an unexpected condition.

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.

So… most likely it is a “typo” or edit-mistake or similar. If you understand what they meant then all is good, no?

Reads like chatgpt, or those insufferable linkedin autogenerated ai questions:

"How would you secure a system?"

This is the embarrassing bit; this is version 4 of a book that predates ChatGPT by years; knowing that probably most of it is written by humans makes me cringe.