5 ms·

> They are defined by the runtime condition they represent. Exactly. Exceptions represent conditions that violate the rules of the computing environment, while

by 9rx 1y ago

> 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 1y ago
> 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 1y ago
  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 1y ago
    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 1y ago
      > 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 1y ago
        > 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
        9rx 1y ago
        > For me, bugs are all mistakes which manifest themselves in software misbehaving. And that's fine. It is not like there is some magical deity in the sky that creates and enforces the law of language. Words are just made up by humans on a whim. If I want to exert my own whim and call that "zigglefritz" instead, that works too.
ninetyninenine 1y ago
>>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.

by 9rx 1y ago

tcfhgj 1y ago

> 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 1y ago
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 1y ago
  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 1y ago
    > 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 1y ago
      > 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
      - 9rx 1y ago
        > For me, bugs are all mistakes which manifest themselves in software misbehaving. And that's fine. It is not like there is some magical deity in the sky that creates and enforces the law of language. Words are just made up by humans on a whim. If I want to exert my own whim and call that "zigglefritz" instead, that works too.

ninetyninenine 1y ago

>>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.