[ninetyninenine]

>Not within the topic’s layer of abstraction. I can see you put a lot of thought into this, and if you were writing in a vacuum it might even be interesting, but discussion relies on context…

You keep invoking “context” as a shield for avoiding substance. Context doesn’t change semantics. Arithmetic faults, null dereferences, and contract violations are not “configurable conventions” no matter how much pseudo-philosophical varnish you apply. Calling fundamental runtime behavior a “configurable convention” is like claiming gravity is optional if you talk about it at the right “layer of abstraction.” It sounds deep until anyone with an actual engineering background reads it.

⸻

>Right. A bug, not an exception. Overloading the use of exception data structures and associated control flows does not imply that there is an exception in concept, just like using an error data structure to represent an email address[1] does not imply that you are dealing with an error in concept. It’s just an email address.

Your “email analogy” is nonsense. The fact that something can be misused doesn’t invalidate its conceptual role. By that logic, if someone writes int banana = "hello", integers stop existing. Exceptions are not defined by their container type. They are defined by the runtime condition they represent. The fact that you have to keep insisting otherwise shows you have no grasp of the operational meaning of exceptions beyond the syntax of throw.

⸻

>Right. A bug, not an exception. Again, just because you overloaded the use of a feature intended for dealing with exceptions for other purposes does not mean that you have an exception in concept. Just as an email address does not become a conceptual error just because you put it in an error data structure[1].

Repeating the same broken analogy doesn’t make it coherent. You keep hammering at this contrived misuse like it proves anything. It doesn’t. It’s a straw man. Nobody is arguing that misusing the mechanism redefines the concept. You’ve constructed a toy example where you intentionally misuse a type and then triumphantly point to your own confusion as evidence. This is the intellectual equivalent of setting your keyboard on fire and declaring that typing is impossible.

⸻

>Right. A bug, not an exception. I sense a recurring theme here. It is clear now that you’ve undeniably confused exceptions (data structure) with exceptions (concept). You obviously missed a lot of context so this may come as a surprise, but we were talking about the concept of programmer error. Data structures used in an implementation find no relevance here.

You’re projecting your own confusion. You can’t even decide which layer you’re talking about. One moment you say exceptions are “data structures,” the next you say the data structure is irrelevant. You wave your hands at “concepts” but those concepts are precisely instantiated through those data structures. You don’t get to discard the implementation layer when it undermines your argument. Pretending the runtime’s behavior is irrelevant to the “concept of programmer error” is a convenient way to avoid admitting that bugs and exceptions are related manifestations of the same fault system. You’re not clarifying categories; you’re just renaming them until they stop overlapping.

⸻

>As bugs and exceptions are different categories within the broader concept of programmer error, you could equally say “In practice many bugs are how bugs announce themselves”. How, exactly, am I to grok that? I honestly have no idea what to make of that statement.

Of course you don’t. The problem isn’t the statement; it’s your refusal to recognize that categories can overlap without collapsing. Saying exceptions often announce bugs is perfectly coherent: bugs are latent causes, exceptions are how those causes surface at runtime. Your confusion stems from trying to turn mutually informative categories into mutually exclusive ones. It’s the same error a freshman makes when they insist that “rain isn’t weather because weather causes rain.”

⸻

[1] The Error("[e-mail]") example doesn’t reveal deep insight; it reveals that you can misuse syntax. That’s not philosophy, it’s just bad code.

[9rx]

> They are defined by the runtime condition they represent.

Exactly. Exceptions represent conditions that violate the rules of the computing environment, while bugs represent conditions that violate "business" rules.

> Saying exceptions often announce bugs is perfectly coherent

Not really. If it were coherent we wouldn't be here. But perhaps what you are grasping to say is that it is possible that a bug could "corrupt" the computing environment, which could then also lead to an exception later on?

Allowing user input of "0" where the business rules say that "0" input is invalid would be considered a bug, and later when that 0 input is used as a divisor would see an exception (in an environment where divide by 0 is not permitted, for those who struggle). The exception in this case would likely reveal that there is also a bug in the user input.

But that does not imply that exceptions encompass bugs. Those are independent events, both wanting their own independent resolutions.

[tcfhgj]

> But that does not imply that exceptions encompass bugs. Those are independent events, both wanting their own independent resolutions.

they do, unless you use exceptions for control flow

[9rx]

Neither exceptions, the concept, nor exceptions, the data structure, have anything to do with control flow. You could be thinking of exception handlers, which refers to a control flow mechanism, but if you were you'd be going completely off the rails.

[tcfhgj]

Do you doubt you can use exceptions for control flow? Of course you need to combine with exception handlers.

It's the only use of exceptions not implying a bug

[9rx]

> Do you doubt you can use exceptions for control flow?

The same way you can use bugs for control flow, I suppose, given that bugs and exceptions are different categories within the same general idea of programmer mistakes. With bugs, of course, being mistakes around "business" rules, and exceptions being mistakes made around computing environment rules.

> Of course you need to combine with exception handlers.

How do you combine a programmer making a mistake with exception handlers? Exception handlers only exist inside programming languages. Are you under the impression that programmers also live inside programming languages? That's... interesting.

[tcfhgj]

> With bugs, of course, being mistakes around "business" rules, and exceptions being mistakes made around computing environment rules.

For me, bugs are all mistakes which manifest themselves in software misbehaving. Maybe it surfaces by a program crash of an uncaught exception or an error message presented to the user, a program termination, a wrong result, ...

> How do you combine a programmer making a mistake with exception handlers?

I write a bug leading to an exception sometimes and catch the exception, then try the operation again, or show an error to the user

[ninetyninenine]

>>They are defined by the runtime condition they represent.

>Exactly. Exceptions represent conditions that violate the rules of the computing environment, while bugs represent conditions that violate “business” rules.

You just moved the goalposts. In real systems the rules are one stack of contracts: language rules, library rules, service rules, business rules. A violation at any layer is a bug relative to that layer’s contract. Many exceptions are thrown for business rules as a matter of design. Examples:

   • ArgumentNullException when a domain service requires a nonempty customer id
   • IllegalStateException when a workflow step is called out of order
   • ValidationException on a failed business invariant

These are not violations of the CPU. They are domain failures surfaced as exceptions by choice. Your split collapses the second we leave toy examples.

⸻

>>Saying exceptions often announce bugs is perfectly coherent >Not really. If it were coherent we wouldn’t be here.

This is rhetoric, not a rebuttal. The production fact is simple. When an unhandled exception takes down a request and that outcome violates the service contract, that incident is triaged as a bug. If it is handled and stays within the contract, it is routine control flow. Teams do this every day without metaphysics.

⸻

>But perhaps what you are grasping to say is that it is possible that a bug could “corrupt” the computing environment, which could then also lead to an exception later on?

No need to reach for corruption. Ordinary causal chains are enough. Bad input passes validation when the spec says it must not. That is a bug. Later division by that input throws. The exception is the observable manifestation of the earlier bug. One cause. One effect. No magic. If your design instead clamps zero or returns a sentinel, then the exception would be the bug. The label follows the spec, not your taxonomy.

⸻

>Allowing user input of “0” where the business rules say that “0” input is invalid would be considered a bug, and later when that 0 input is used as a divisor would see an exception … The exception in this case would likely reveal that there is also a bug in the user input.

You have just restated that exceptions announce bugs. Your own example concedes the point you claimed was incoherent. The exception is how the system made the hidden violation visible. That is exactly what observability is for.

⸻

>But that does not imply that exceptions encompass bugs. Those are independent events, both wanting their own independent resolutions.

Independent events would mean no causal relation. Yet your own scenario shows a direct chain from the validation bug to the later exception. They are linked by cause and effect and are handled together in a single incident. Ops does not file two unrelated tickets and pretend the crash and the root cause are strangers.

⸻

The correct model is simple and general:

   • A spec defines allowed states at every layer.
   • A bug is entry into a disallowed state relative to that spec.
   • An exception is a mechanism that signals some disallowed states.

From this it follows:

   • Many bugs surface as exceptions.
   • Some exceptions are not bugs because the spec expects and handles them.
   • Some bugs do not raise exceptions because the language or code does not signal them.

Your attempt to split computing environment rules from business rules ignores that both are contracts, and violations of either are bugs. Your own examples demonstrate the causal link you say does not exist.

[9rx]

> You just moved the goalposts.

Nope. This carries the exact same semantic intent as my original comment. I've had to severely dumb down the phrasing over the course of discussion as it is clear you don't have a firm grasp on computing, and may continue to dumb it down even more if you continue to display that you don't understand, but there is nowhere for the goalposts to go. They were firmly set long before my time and cannot be moved.

> and violations of either are bugs.

They are both programmer error. "Bug" and "exception" are different labels we use to offer more refinement in exactly what kind of error was made. If I erroneously write code that operates on a null pointer, contrary to the rules of the computing environment, I created an exception. If I erroneously wrote code to paint a widget blue when the business people intended it to be red, I created a bug. While you may not understand the value in differentiating — to the user who only sees that the program isn't functioning correctly it is all the same, right? — programmers who work on projects in industry do, hence why they created different words for different conditions.

> the language or code does not signal them.

It seems you continue to confuse the exception data structure with exception as a categorical type of programmer error. The discussion is, was, and will only ever be about the later. There was no mention of programming languages at the onset of our discussion and turning us towards that is off-topic. You seem to be here in good faith, so let's keep it that way by staying true to the original topic.

[tcfhgj]

> If I erroneously try to operate on a null pointer, I created an exception.

This is only true if some library/framework you use creates an exception for you.

Why do you operate on a null pointer in the first place? Well, you didn't because you painted something in the wrong color, but because you passed a null pointer to a piece of code, which should not have received a null pointer.

[9rx]

> This is only true if some library/framework you use creates an exception for you.

No. That's like saying you can't have errors unless you language/library/framework has an error datatype. Quite possibly the stupidest thing I've ever heard. A language doesn't need exception data structures or exception handlers for a programmer to violate a rule of the computing environment.

[tcfhgj]

So the language/library/framework does not create an exception when operating on the null pointer, but instead it does not do anything (when it should change the color of a widget from blue to red).

Now you have a bug by operating on a null pointer, which supposedly is an exception, while exceptions cannot be bugs?