On 2014-10-04 12:29, Steven Schveighoffer wrote:
Then what is the point of File's constructor throwing an exception? This means, File is checking the filename, and I have to also check the file name.
"File" should check if the file exists, can be opened and similar things. These are things that can change from outside your application during a function call between your application and the underlying system.
But, if "File" for some reason doesn't accept null as a valid value then that's something the developer of the application that uses "File" is responsible to check. It's not like the value can suddenly change without you knowing it.
Right, that is fine. If you catch the exception and handle the result with a nice message to the user, that is exactly what should happen. If you forget to catch the exception, this is a bug, and the program should crash with an appropriate stack trace.
Yes, I agree.
Note 2 things: 1. You should NOT depend on the stack trace/Exception to be your error message.
Agree.
2. File's ctor has NO IDEA whether throwing an exception is going to be a bug or a handled error condition.
Yes, but it's the responsibility of "File" to properly document what exceptions it can throw and during which conditions. Then it's up to the developer that uses "File" to handle these exceptions appropriately.
I would say, as soon as an exception is thrown and is not caught by user code, for all intents and purposes, it becomes an Error.
Sure. In theory you can have an other library that handles these exceptions. Think something like a web framework that turns most exceptions into 500 responses.
-- /Jacob Carlborg
