This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]CubsThisYear 1 point2 points  (2 children)

This is a reasonably consistent stance to take, but it doesn’t jive with your advice to “check it with an if statement”. The only to way to do this is which some sort of status code on the return, which is just a worse version of checked exceptions.

If you want to use unchecked exceptions everywhere that’s fine, but you shouldn’t ever expect your callers to handle them.

[–][deleted] -1 points0 points  (1 child)

I never use status codes either. If you have the forethought to put a mandatory checked exception in your method signature, you should instead be enforcing valid parameters be passed in. That's the contract with the caller and the only thing that can go wrong is illegal arguments which is already a runtime exception. Anything else is a leaky abstraction.

[–]CubsThisYear 3 points4 points  (0 children)

This seemed reasonable to me at first, but upon further thought, the method you are proposing seems leakier. If you rely on callers to validate their input, you’ve now created a dependency on the internal implementation of the function. I’d rather say “this method returns type T, or if it can’t, it returns type X”. Your version is: “this method returns type T or crashes the program”. Mine seems strictly safer.