What the user expects when error happens?

[Ubermann]

This is: lets say a function requires a file name to be passed to open it, then we do some operations and finally we return some USERDATA.

But the user writes "foo.pngg" instead "foo.png". That file does not exist, so the function should return something instead of simply crashing there. The function couldn't do anything because the file name was a mandatory parameter necessary for all operations.

And here is the problem: what do you think the function should return? false? a string describing the error? nil? an empty strong?...

Because the function is expected to return some kind of data the will be used later on, if the data is USERDATA, but we return false due to error, then the program will crash anyway when we are trying to use that supposed USERDATA returned by the function.

What is your opinion?

[bartbes]

I expect it to error.

This is also important, in high-uptime systems, it is common to "crash early", why? Well, because if you don't crash when there's a reason to, instead you return or keep some invalid state, everything will break later, maybe not in a controlled fashion, data is lost, the application completely breaks, and the worst part is, you're going to have a hard time tracking it down, because which one of these many functions was annoying enough to return nil? Which input was invalid?

[Ubermann]

I expect it to error.

This is also important, in high-uptime systems, it is common to "crash early", why? Well, because if you don't crash when there's a reason to, instead you return or keep some invalid state, everything will break later, maybe not in a controlled fashion, data is lost, the application completely breaks, and the worst part is, you're going to have a hard time tracking it down, because which one of these many functions was annoying enough to return nil? Which input was invalid?

That makes sense.

Then, returning FALSE instead the expected USERDATA will be a good choice so the program crashes when the expected USERDATA is used, so only need to track down one function.

[Nixola]

Do you know that you can raise custom errors with the function error(message)?

[bartbes]

I was for crashing in your function, not returning something worthless .

[Inny]

I'm of two opinions here that aren't incompatible.

1. Crash Early Crash Often. Software should always be written to the highest standard of correctness. If you have the option of crashing, or continuing forward with incorrect data, choose to crash.
2. User Error should never cause the program to crash. Because the user is always right, so to speak. If they typed foo.pngg, maybe that's exactly what they meant. Your program should go back with its hat in its hands, hanging its head, and apologize for not being smart enough to find foo.pngg.

It seems like a cognitive dissonance, but the reality is that we have two different types of source code that have to live together in the same program. They go by many names: Mechanism and Policy, Plumbing and Porcelain, and so on. So, what you have to do as a programmer is learn to split the two up, learn which is which, and make sure your Mechanism code is what crashes when given incorrect data, and that your Policy code checks everything to make sure that no errors are allowed to get down to the Mechanism code.

[Robin]

What Inny said. When you make a mistake, the game should crash. If the user makes a mistake (or does something else unexpected), the game should not lose its cool and instead either ignore it or talk to the user about it, depending on the situation. (A certain program we had to use for a certain course on the uni complained if you clicked on something that was not a button or a text field. Don't do that.)

[bartbes]

Ehm, it is important we define user here, though.
If we're talking about an end-user, then no errors, but a message would be nice.
If we're talking about lovers, CRASH THE HELL OUT OF THINGS, nothing as annoying as not knowing what went wrong, also considering file access is usually a critical thing, I doubt the code could fall back on something and provide decent results anyway, if you're returning something broken, you might as well be loud about it.

[kikito]

Ehm, it is important we define user here, though.
If we're talking about an end-user, then no errors, but a message would be nice.
If we're talking about lovers, CRASH THE HELL OUT OF THINGS, nothing as annoying as not knowing what went wrong, also considering file access is usually a critical thing, I doubt the code could fall back on something and provide decent results anyway, if you're returning something broken, you might as well be loud about it.

+1 to the difference in "users". A gamer playing a game -> helpful message saying "could not find the file". A programmer using a library -> error (make sure he's got a way to check for file existence before calling your function, so he can provide the right experience to the gamer).

[Ubermann]

+1 to the difference in "users". A gamer playing a game -> helpful message saying "could not find the file". A programmer using a library -> error (make sure he's got a way to check for file existence before calling your function, so he can provide the right experience to the gamer).

And this is the exact problem.

My piece of software is in fact a library. It doesn't have any kind of debug info output. I mean, the user may be missing information on what was the error if he doesn't have any console or MsgBox() function implemented, or even guess why the app crashed if I don't use anything that is not error(), which forces app crashing in the love window itself.

But then, if the app is using the library and in some point the app requires the user to insert "foobar.png", and he inserts "foobar.pngg" by mistake, and I throw and error(), the user may lost a lot of work. Let's say someone uses my library in a Photoshop-like program. If the app simply crashes, he me lost hours of work.