The chief reason software fails is because programmers are insufficiently aware of all of the reasons the software can fail. Sure you need a test to make sure that you handle the error correctly, but if the function signature doesn't indicate the possibility of an error occurring, why would you write that test in the first place?
By the same reasoning, if the function signature doesn't indicate what specific errors can occur, why would you write a test in the first place?
No matter how you slice it you have to figure out what the software you are calling upon does and how it is intended to function. Which is, too, why you are writing tests: So that your users have documentation to learn that information from. That is what tests are for. That is what testing is all about! That it is also executable is merely to prove that what is documented is true.
Let us introduce you to the concept of checked exceptions. That is one of the few paradigms we've seen in actually-used languages (namely Java) where communicating which specific errors will occur has been tried.
Why is it that developer brains shut off as soon as they see the word "error"? It happens every time without fail.
I'm aware of checked exceptions in Java. What I'm not aware of is a language which has checked exceptions as the only exception mechanism, which would be the only way to have exceptions always reflected in the function definition.
