-
1. What is the rationale for having many model-related methods throw exceptions on error, and return null instead?
Generally the benefit of the exceptions being thrown is if the calling code can perform some useful action based on the nature of the problem.
So in the case of the parser - does it help a calling app to know that the input stream has a problem, versus a problem with the model obtained from that input stream?
-
2. What is the rationale for having many model-related methods throw exceptions on error, and return null instead?
Gary Brown wrote:
Generally the benefit of the exceptions being thrown is if the calling code can perform some useful action based on the nature of the problem.
So in the case of the parser - does it help a calling app to know that the input stream has a problem, versus a problem with the model obtained from that input stream?
I think these are two different problems, and for both, an app can act on it (ask the user to pick another file/correct it). So I'd go for exceptions for both problems (I tend to prefer RuntimeExceptions always, but I'll follow your standards there).
I think it's quite surprising to just get a null value with no exceptions (it certainly bit me at first).
-
3. What is the rationale for having many model-related methods throw exceptions on error, and return null instead?
I think it is personal preference - I prefer to have a null return represent the fact that the parser was not able to return a valid model, and then the journal provide the details of what the problem was.
However I think removing the IOException is fine, so not forcing the client app to define an exception handler - and instead just check for return value being null - so even IO issues would be reported to the journal.
-
4. What is the rationale for having many model-related methods throw exceptions on error, and return null instead?
Don't bother then, I just don't like having to check for null all the time, but I don't mind the IOException much.