[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?

[9rx]

> So the language/library/framework does not create an exception when operating on the null pointer

It creates an exception in concept. It might not create an exception data structure, depending on the particulars of the language/library/framework. Which are you referring to when you say "exception" here?

It is a bit unfortunate that we've come to use "exception" to mean different things in different contexts. They are not dependent, though. Just as you can have an error in concept without an error data structure, you can have an exception in concept without an exception data structure.

[tcfhgj]

> It creates an exception in concept. It might not create an exception data structure, depending on the language/library/framework. Which are you referring to when you say exception here?

it creates an exception (your concept), but no exception (data structure)

[9rx]

Right. Glad you understand now.