4 ms·

> Moreover, the client doesn’t care if an IOException or a SqlException is thrown. He just wants to know, if something went wrong. Consequently the thrown excep

> Moreover, the client doesn’t care if an IOException or a SqlException is thrown. He just wants to know, if something went wrong. Consequently the thrown exception should be implementation agnostic. My Java is very rusty at this point. But it looks like both SQLException and IOException are derived from Exception, so you could just specify the interface as: UserRepository.getUsers(Path) throws Exception No? An alternative would be to create a RepositoryException class, and warp the IO-/SQL-Exeptions into an instance of RepositoryException. In any case I don't see a flaw with specifying an Exception type in the interface. It tells the developer concisely: "This can go wrong, and you should plan for this". And it's clearly better than C-style return codes which are hard to interpret and easy to ignore. In the specific case of IO, I don't think whether a method involves IO or not is an implementation detail that should be hidden. IO is very costly and has very different failure scenarios than memory accesses/computation. You should always know whether you are calling a function or a remote service.

kitd 8y ago
Your alternative 'RepositoryException' is considered the better practice. I believe Bloch recommends it in Effective Java.
raziel2p 8y ago
You could, but there are also tons of other Exceptions which you don't want the user of your method to explicitly handle because they are bugs in your program that should be handled globally or cause the program to restart.
leothekim 8y ago
I can't tell you how many times I've had to write code to open a file that I know will always exist and have to write an empty try-catch. Or had to add an unused throws clause because an interface specified it. Sometimes I've even had to throw a different type of exception than declared by an interface method and was left to either refactor tons of code to uselessly handle the new checked exception or throw a runtime one and catch it at the smaller number of callsites, or throw it as one of the declared checked exceptions that would not accurately describe the type of error to be handled. Anyone use Hibernate and see how many times an underlying SQLException got wrapped by a HibernateException? For functional programming languages, I think it's a lot more convenient to not have checked exceptions because how they affect the composability of closures. Not saying it's impossible, but imagine having to add throws clauses to your .map and .filter chains.
- heinrichhartman 8y ago
  > Sometimes I've even had to throw a different type of exception than declared by an interface method and was left to either refactor tons [...] I see that this is inconvenient. This might be the essence of the whole thing here. It is way worse than adding a new argument to a function! 1. There is no way to overload a function with different Exception clauses. 2. You not only need to touch the call sites but also parts of the stack that led to the call sites. > I've had to write code to open a file that I know will always exist How can you ever be sure a file exists? I can be sure a function or a variable exists if I declared it. Files can be manipulated by other processes, USB drives are ejected, etc. You can never be sure they stay where it was. Even if I created the file one line above, I technically still have a potential race condition. > For functional programming languages, I think it's a lot more convenient to not have checked exceptions. There is a clear tradeoff here. E.g. when writing python or bash scripts I seldom care to catch errors. Let it crash fast and return a stack trace. For production grade software you usually want to much more careful and handle exceptions explicitly. Checked exceptions are clearly targeted for the latter.
  - leothekim 8y ago
    > How can you ever be sure a file exists? Well I can't ever be sure, but the example I'm thinking of is looking up a config file on the file system that was copied there by a deployment script. If it didn't exist, a RuntimeException failing the application would be entirely appropriate. If I was checking for a file on a USB drive or some other source, I'd very much have a try-catch. Do I need checked exceptions in this case? Still debatable in my opinion. WRT checked exceptions targeted for production grade software, curious what you think about the (lack of) checked exception handling in Java 8 lambdas.
- choward 8y ago
  > I can't tell you how many times I've had to write code to open a file that I know will always exist and have to write an empty try-catch. How do you know that the file will always exist? I'm pretty sure you don't. The try catch shouldn't be empty. Now it's going to crash when you try reading or writing from the file so all you did was make it so it blows up with a less helpful error later.

kitd 8y ago

Your alternative 'RepositoryException' is considered the better practice. I believe Bloch recommends it in Effective Java.

raziel2p 8y ago

You could, but there are also tons of other Exceptions which you don't want the user of your method to explicitly handle because they are bugs in your program that should be handled globally or cause the program to restart.

leothekim 8y ago

I can't tell you how many times I've had to write code to open a file that I know will always exist and have to write an empty try-catch. Or had to add an unused throws clause because an interface specified it. Sometimes I've even had to throw a different type of exception than declared by an interface method and was left to either refactor tons of code to uselessly handle the new checked exception or throw a runtime one and catch it at the smaller number of callsites, or throw it as one of the declared checked exceptions that would not accurately describe the type of error to be handled. Anyone use Hibernate and see how many times an underlying SQLException got wrapped by a HibernateException? For functional programming languages, I think it's a lot more convenient to not have checked exceptions because how they affect the composability of closures. Not saying it's impossible, but imagine having to add throws clauses to your .map and .filter chains.

heinrichhartman 8y ago
> Sometimes I've even had to throw a different type of exception than declared by an interface method and was left to either refactor tons [...] I see that this is inconvenient. This might be the essence of the whole thing here. It is way worse than adding a new argument to a function! 1. There is no way to overload a function with different Exception clauses. 2. You not only need to touch the call sites but also parts of the stack that led to the call sites. > I've had to write code to open a file that I know will always exist How can you ever be sure a file exists? I can be sure a function or a variable exists if I declared it. Files can be manipulated by other processes, USB drives are ejected, etc. You can never be sure they stay where it was. Even if I created the file one line above, I technically still have a potential race condition. > For functional programming languages, I think it's a lot more convenient to not have checked exceptions. There is a clear tradeoff here. E.g. when writing python or bash scripts I seldom care to catch errors. Let it crash fast and return a stack trace. For production grade software you usually want to much more careful and handle exceptions explicitly. Checked exceptions are clearly targeted for the latter.
- leothekim 8y ago
  > How can you ever be sure a file exists? Well I can't ever be sure, but the example I'm thinking of is looking up a config file on the file system that was copied there by a deployment script. If it didn't exist, a RuntimeException failing the application would be entirely appropriate. If I was checking for a file on a USB drive or some other source, I'd very much have a try-catch. Do I need checked exceptions in this case? Still debatable in my opinion. WRT checked exceptions targeted for production grade software, curious what you think about the (lack of) checked exception handling in Java 8 lambdas.
choward 8y ago
> I can't tell you how many times I've had to write code to open a file that I know will always exist and have to write an empty try-catch. How do you know that the file will always exist? I'm pretty sure you don't. The try catch shouldn't be empty. Now it's going to crash when you try reading or writing from the file so all you did was make it so it blows up with a less helpful error later.