[9rx]

Bugs require execution so a compiler cannot find bugs.

Exceptions also require execution, but that does not suggest that they are encompassed by bugs. The lack of a third term tells that there is no overlap. If "bug" covered both exceptions and where human expectations are violated, there would necessarily be another term just for the case where human expectations are violated. But there is no such term...

...that I've ever heard. If it is that I've been living under a rock, do tell.

[ninetyninenine]

No you haven’t been living under a rock your definitions are just off and you didn’t read carefully what I wrote. Or you’re just overly pedantic.

I wrote bugs can cover exceptions. Think hard about what that sentence means in English. If I can do something it means I can both do something and not do something. So that means there are exceptions that are bugs and exceptions that are not bugs.

The reason why it’s important to illustrate this difference is because a large, large number of exceptions occur as a bug.

[9rx]

> So that means there are exceptions that are bugs

Which, like before, is false. Are you, perhaps, confusing exceptions (the concept; what we're talking about here) with the data structure of the same name? A bug could erroneously lead to the creation of an exception (data structure), but that wouldn't be an exception (concept), that'd just be a bug.

There is no situation where an exception (concept) is also a bug, unless you take "bug" to mean something akin to general "programmer error", where exceptions are subset thereof. But, as before, we know that's not how "bug" is used as there is no other terminology for human expectation violations to fill the void. No need as that is already what "bug" refers to.

> a large, large number of exceptions occur as a bug.

That doesn't really make any sense. Maybe if, again, you have confused exceptions (concept) with exceptions (data structure), then it could start to mean something, but even then "large, large" is one hell of a claim. Let's be real: The vast majority of exceptions (data structure) are created by programmers who mistakenly believe that "exception" is another word for "error". While not exactly a good idea, that use falls under neither exceptions (concept) nor bugs. In second place, exceptions (data structure) are created due to exceptions (concept). I'm sure exceptions (data structure) being created due to bugs has happened before, but I've never seen it.

[ninetyninenine]

You’re arguing as though reality cares about your word boundaries. Saying “exceptions are not bugs” because one is a concept and the other is a data structure is like saying a flat tire isn’t a car problem because the air is outside the vehicle. It’s technically true in the same way “rain is just water, not weather” is true. Nobody outside the argument needs a whiteboard to see what’s gone wrong.

An exception is what happens when a bug hits the runtime. The program trips, falls, and throws a message about it. Calling that “not a bug” is like saying your toaster catching fire isn’t a malfunction because combustion is a physical process, not an electrical one. Or saying a sinking ship isn’t in trouble because “leak” is a noun and “disaster” is a category.

In practice, exceptions are how bugs announce their presence. You can keep redrawing the philosophical fence around which one counts as which, but it’s the same as a child insisting the spilled milk isn’t a mess because it’s just “liquid on the table.” Everyone else has already grabbed the paper towels.

[9rx]

> An exception is what happens when a bug hits the runtime.

Remember, "exception" is short for "exceptional event". "An exceptional event is what happens when a bug hits the runtime." means... what, exactly? And let's not forget that you said that not all exceptions are bugs so it seems we also have "An exceptional event is what happens when a bug does not hit the runtime." What is that supposed to mean?

Returning us from la-la land, an exceptional event, or exception, refers to encountering a fundamental flaw in the instruction. Something like divide by zero or accessing an out of bounds index in an array. Things that you would never have reason to carry out and that a more advanced compiler could have reasonably alerted you to before execution.

Bugs are different. They can only be determined under the watchful eye of a human deciding that something isn't behaving correctly. Perhaps your program has a button that is expected to turn on an LED, but instead it launches a nuclear missile. While that is reasonably considered programmer error, that's not a fundamental flaw — that's just not properly capturing the human intent. In another universe that button launching nuclear missiles very well could be the intended behaviour. There is no universe where accessing an out of bounds index is intended.

> exceptions are how bugs announce their presence

Bugs aren't announceable, fundamentally. They can be noticed by a human who understands the intent of the software, but it is impossible for the machine to determine what is and what isn't a bug. The machine can determine what is an exception, though, and that's why exceptions often get special data structures and control flows in programming languages while bugs don't.

[ninetyninenine]

You’re still mistaking your own definitions for truth. You’re describing programming as if words create reality, not the other way around. Your claim that bugs “can only be determined by humans” and “machines cannot announce them” is like saying a car cannot have a problem until a mechanic gives it a name. The smoke pouring from the hood does not wait for linguistic permission to exist.

Exceptions are the runtime form of program faults. The fact that we can construct them synthetically or that some are anticipated does not erase their relationship to bugs. You seem to believe that because we can imagine a world where launching a missile is “intended,” it stops being a bug. By that logic, nothing in computing can ever be wrong as long as someone somewhere hypothetically wanted it that way. That isn’t philosophy. It’s a child’s loophole.

Your “fundamental flaw in the instruction” definition collapses immediately under reality. A division by zero is only “fundamental” because of human intent: we chose to define arithmetic that way. Under your logic, if we wrote a compiler that quietly handled it as infinity, exceptions would vanish from the universe. That should tell you that your ontology is not describing truth but just the current convention of language design.

The machine can’t “determine” bugs? Of course it can’t. The machine can’t determine anything. It executes. Yet you just admitted exceptions exist because “the machine determines them.” You’ve built a castle out of circular definitions and are calling it a worldview.

In practice, exceptions are one of the main observable ways that bugs manifest. The rest of us live in the world where programs crash, not in the world where we rename crashes until they sound academic.

[9rx]

> [...] is like saying a car cannot have a problem until a mechanic gives it a name. The smoke pouring from the hood does not wait for linguistic permission to exist.

That doesn't make any sense. But there may be something salvageable in your analogy. Consider the difference between manufacturing defects and wear and tear. You can understand how each, while both able to lead to failure, are different categories of problems?

Good. Now, analogies can only go so far, but we can extrapolate some similarity from that in software. Meaning that both bugs and exceptions are problems, but they are not of the same category. They originate from different conditions. Exceptions are fundamental flaws in the code, while bugs are deviation from human intent.

> Yet you just admitted exceptions exist because “the machine determines them.”

That's right. The machine can determine when an exception occurs. For example, divide by zero. There is no way the machine can carry on once this happens. The machine is capable of addressing such a condition. Which is very different from divide by one when you actually intended to divide by two. This is what differentiates exceptions from bugs and why we have more than one word to describe these things.

> exceptions are one of the main observable ways that bugs manifest.

Maybe you're still confusing the concept with the data structure? Absolutely, a bug can lead to creating an exception (data structure). Consider:

    color sky = "blue";
    if (sky == "blue") { // was intended to be sky != "blue"
        throw "the sky was expected to be blue"; // produces an exception data structure (message, call stack, etc.)
    }

But that wouldn't be an exception (concept), that'd just be a bug. The fault is in the inverted conditional, not a fundamental execution flaw.

The presence of an exception (data structure) does not imply that there is an exception (concept). The overlapping use of words is a bit unfortunate, perhaps — albeit consistent with error (concept) and error (data structure), but the difference between a data structure and a concept should not confuse anyone.

Exceptions (concept), on the other hand, looks more like:

    object.methodThatDoesNotExist();

The code is fundamentally flawed. The machine is, in this case, quite able to determine that you screwed up. If you have a sufficiently advanced compiler, you'd be warned at compile time that methodThatDoesNotExist cannot be called. But if that condition evades the compiler then it would lead to an exceptional event at run time instead.