What the user expects when error happens?

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
User avatar
Ubermann
Party member
Posts: 146
Joined: Mon Nov 05, 2012 4:00 pm

What the user expects when error happens?

Post by 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?
User avatar
bartbes
Sex machine
Posts: 4946
Joined: Fri Aug 29, 2008 10:35 am
Location: The Netherlands
Contact:

Re: What the user expects when error happens?

Post by 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?
User avatar
Ubermann
Party member
Posts: 146
Joined: Mon Nov 05, 2012 4:00 pm

Re: What the user expects when error happens?

Post by Ubermann »

bartbes wrote: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.
User avatar
Nixola
Inner party member
Posts: 1949
Joined: Tue Dec 06, 2011 7:11 pm
Location: Italy

Re: What the user expects when error happens?

Post by Nixola »

Do you know that you can raise custom errors with the function error(message)?
lf = love.filesystem
ls = love.sound
la = love.audio
lp = love.physics
lt = love.thread
li = love.image
lg = love.graphics
User avatar
bartbes
Sex machine
Posts: 4946
Joined: Fri Aug 29, 2008 10:35 am
Location: The Netherlands
Contact:

Re: What the user expects when error happens?

Post by bartbes »

I was for crashing in your function, not returning something worthless ;).
User avatar
Inny
Party member
Posts: 652
Joined: Fri Jan 30, 2009 3:41 am
Location: New York

Re: What the user expects when error happens?

Post by 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.
User avatar
Robin
The Omniscient
Posts: 6506
Joined: Fri Feb 20, 2009 4:29 pm
Location: The Netherlands
Contact:

Re: What the user expects when error happens?

Post by 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.)
Help us help you: attach a .love.
User avatar
bartbes
Sex machine
Posts: 4946
Joined: Fri Aug 29, 2008 10:35 am
Location: The Netherlands
Contact:

Re: What the user expects when error happens?

Post by 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.
User avatar
kikito
Inner party member
Posts: 3153
Joined: Sat Oct 03, 2009 5:22 pm
Location: Madrid, Spain
Contact:

Re: What the user expects when error happens?

Post by kikito »

bartbes wrote: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).
When I write def I mean function.
User avatar
Ubermann
Party member
Posts: 146
Joined: Mon Nov 05, 2012 4:00 pm

Re: What the user expects when error happens?

Post by Ubermann »

kikito wrote:
+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.
Post Reply

Who is online

Users browsing this forum: No registered users and 36 guests