3 ms·

I am having a lot of trouble giving you the benefit of the doubt, since what you seem to be arguing for is leaving API contracts completely ambiguously defined

I am having a lot of trouble giving you the benefit of the doubt, since what you seem to be arguing for is leaving API contracts completely ambiguously defined because it's too much effort for you to do otherwise. You're not arguing for correctness, or for reliability, but rather for your own convenience in the face of something you find burdensome. That is uninteresting to me. This subject has been hashed to death, we're repeating the same arguments. You want to leave things ambiguous, I want to ensure that behavior is well-defined. You're right that this has been abandoned by other languages. In many of those languages -- including Scala -- you can make use of Either/Option monads to achieve the same effect without exceptions at all. In others, you just have to either expend a bunch of mental effort to ensure you code defensively, or take your approach of spinning the chamber and hoping for the best. Your argument for "well defined points" only begins to make sense in purely functional languages. Otherwise, there's no way to guarantee a lack of side-effects in your use of atomic-goto, and the result is invariably that the software is unreliable and prone to strange stateful failure.

jontro 14y ago
Working with the org.json.JSON classes is what made me switch my mind about the use of checked exceptions. Catching these checked exceptions makes no sense at all.
- pifflesnort 14y ago
  That API in particular has 'opt' variants of its accessors that return NULL rather than throwing an exception. That said, a standard clean usage model for the checked variants would be to declare a 'throws' from your JSON parsing code, and then at a higher level wrap that in an InvalidMessageException or similar. The non-checked approach would be to check for NULLs and ensure that none escape your parsing code. The only time the checked version becomes burdensome is if you don't encapsulate your JSON -> app model parsing in a single place, and instead sprinkle the code with unencapsulated JSON parsing. In that case, I believe the problem is a lack of encapsulation, not the checked exceptions -- the exceptions just highlights that one is not separating concerns between code that must be aware of parsing issues and potentially invalid data, and code that can be guaranteed to only operate on valid and whole data.

jontro 14y ago

Working with the org.json.JSON classes is what made me switch my mind about the use of checked exceptions. Catching these checked exceptions makes no sense at all.

pifflesnort 14y ago
That API in particular has 'opt' variants of its accessors that return NULL rather than throwing an exception. That said, a standard clean usage model for the checked variants would be to declare a 'throws' from your JSON parsing code, and then at a higher level wrap that in an InvalidMessageException or similar. The non-checked approach would be to check for NULLs and ensure that none escape your parsing code. The only time the checked version becomes burdensome is if you don't encapsulate your JSON -> app model parsing in a single place, and instead sprinkle the code with unencapsulated JSON parsing. In that case, I believe the problem is a lack of encapsulation, not the checked exceptions -- the exceptions just highlights that one is not separating concerns between code that must be aware of parsing issues and potentially invalid data, and code that can be guaranteed to only operate on valid and whole data.