Program logic bugs vs input/environmental errors

[Jacob Carlborg via Digitalmars-d]

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