[EvanAnderson]

Also: Let API calls fail and return errors instead of trying to "predict" errors and be "helpful" to the user. You don't know how people are going to use the software you've written in the future.

Example: Old software that can't handle larger-than-expected disk free space. There are AppCompat shims in Windows for lying to applications re: free disk space quantity because some old applications stored the result of disk free queries in 32-bit integers. Who would ever have more than 4GB of free disk?!?

The integer overflows that result invariably cause unexpected behavior.

Just make the API call to write to the disk. If that returns "disk full" let the user know. Don't "check" first.

[tgsovlerkhgsel]

I want to know that there isn't enough disk space before going through a half-hour installation process...

[spicybright]

Surprisingly, some really old windows software installers will ask you want to run the install anyways even after it determines there's not enough space. That seems to be the ideal solution.

[ben0x539]

> Just make the API call to write to the disk. If that returns "disk full" let the user know. Don't "check" first.

idk. Things don't always behave super gracefully if the disk is actually entirely full, this could lead to data loss as other applications can't persist their state as they expect to be able to.

[dude187]

I think you have a good point but with the worst example. Though the example is good in that it shows the nuance of how it's clearly not always the best choice.

If you're doing something like a system update where you're updating shared libraries, you don't want to get the kernel and glibc yet only half the libraries. You could easily end up in a state where you're not able to rerun the install or even free space without booting up a live USB or something.

[eyelidlessness]

Let something overflow seems like the exact opposite of empowering user decision.