Hello, thanks for the appreciation.
Well, to be honest, I have never heard of this perspective on the subject.
Let's say that I understand the point on checked exception, it's mine too, I can also see the point on unchecked even if, as you say, it's difficult to decide on behalf of your consumer on what is fatal or not and I would also argue that if an event is indeed fatal it should modelled as an Error more than a RuntimeException (given it's fatal nature), leading again to the conclusion that RuntimeExceptions are in the end GOTOs in disguise.
Thanks for the response. I agree an error could be better than an exception there, and also gives the consumer more control. Determining behavior for not only what you control, but also what your consumers control makes developing anything meant to be for generic use difficult.
Thanks again and great post!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hello, thanks for the appreciation.
Well, to be honest, I have never heard of this perspective on the subject.
Let's say that I understand the point on checked exception, it's mine too, I can also see the point on unchecked even if, as you say, it's difficult to decide on behalf of your consumer on what is fatal or not and I would also argue that if an event is indeed fatal it should modelled as an Error more than a RuntimeException (given it's fatal nature), leading again to the conclusion that RuntimeExceptions are in the end GOTOs in disguise.
Thanks for the response. I agree an error could be better than an exception there, and also gives the consumer more control. Determining behavior for not only what you control, but also what your consumers control makes developing anything meant to be for generic use difficult.
Thanks again and great post!