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