4 ms·
That depends a bit on the definition I guess - let me explain why: If you call a method in e.g. Java which is annotated to return a string, then by definition
by valenterry 3y ago
That depends a bit on the definition I guess - let me explain why:
If you call a method in e.g. Java which is annotated to return a string, then by definition you have to expect the following possible outcomes:
- The method returns a string
- The method throws an exception (or rather: a Throwable)
- The method does not return at all
That's just how it is in Java and also in most other languages. Therefore, throwing an exception must always be expected. Only if there were only checked exceptions and no unchecked exceptions this would be different - but then how do you handle things like Stackoverflow or OOM exceptions?
In fact, if a methods says it returns a string, what that really means is that that it will not return something else than a string. That is the real meaning. It cannot e.g. return an integer. But that's about all the guarantees that it gives.
So you see, it's tricky.
There are however languages where you can really rely on that they do return what they claim. But those languages then force you to prove that a method actually returns within a finite amount of time and such things. Not very practical to use in many cases.