Return to Answer

I deeply believe in fail fast myself. The idea is to help debugging devs by getting them as close to the cause of the issue as possible so they don't have to slog through file after file trying to figure out where a bad value came from.

However, file I/O is not something you should pretend you control. You don't. You're never going to. Say you test that the file exists and then try to use it. Well then Murphy will wait until your code is deployed on a critical system to delete, rename, or move that file between when you tested it and when you attempted to use it.

Every time you use a file, suspect that it might not be there and be ready for it. Nothing you do before hand absolves you of this. It's simply the reality of how I/O works. Don't pretend Murphy won't do this because your app is the only one on the system. If Murphy has to he'll take the form of a rat that gnaws through your data cable.

On top of that, why throw an error if the file doesn't exist? Maybe this is a chance to make the file exist without hassling the user. Fail fast doesn't mean be pessimistic.

If the system is c:\MS\Windows and the user is typing /dev/nul you could be nice and parse their input and realize it's unusable. This is validation. It's the ONE thing constructors should do besides set instance variables. It's not about the current state of the file system. It's about whether your input is crap.

Validation can't involve talking to peripherals. In fact the thing you're validating must be full blown immutable or the test is a waste of time.

Fail fast should never overturn this. Fail fast argues that once attempting to use the file has caused an error you should get that exception going now, not later. But also, not before.

I deeply believe in fail fast myself. In addition to promoting system integrity it helps debugging devs by getting them as close to the cause of the issue as possible so they don't have to slog through file after file trying to figure out where a bad value came from.

However, file I/O is not something you should pretend you control. You don't. You're never going to. Say you test that the file exists and then try to use it. Well then Murphy will wait until your code is deployed on a critical system to delete, rename, or move that file between when you tested it and when you attempted to use it.

Every time you use a file, suspect that it might not be there and be ready for it. Nothing you do before hand absolves you of this. It's simply the reality of how I/O works. Don't pretend Murphy won't do this because your app is the only one on the system. If Murphy has to he'll take the form of a rat that gnaws through your data cable.

On top of that, why throw an error if the file doesn't exist? Maybe this is a chance to make the file exist without hassling the user. Fail fast doesn't mean be pessimistic.

If the system is c:\MS\Windows and the user is typing /dev/nul you could be nice and parse their input and realize it's unusable. This is validation. It's the ONE thing constructors should do besides set instance variables. It's not about the current state of the file system. It's about whether your input is crap.

Validation can't involve talking to peripherals. In fact the thing you're validating must be full blown immutable or the test is a waste of time.

Fail fast should never overturn this. Fail fast argues that once attempting to use the file has caused an error you should get that exception going now, not later. But also, not before.

I deeply believe in fail fast myself. The idea is to help debugging devs by getting them as close to the cause of the issue as possible so they don't have to slog through file after file trying to figure out where a bad value came from.

However, file I/O is not something you should pretend you control. You don't. You're never going to. Say you test that the file exists and then try to use it. Well then Murphy will wait until your code is deployed on a critical system to delete, rename, or move that file between when you tested it and when you attempted to use it.

Every time you use a file suspect that it might not be there and be ready for it. Nothing you do before hand absolves you of this. It's simply the reality of how I/O works. Don't pretend Murphy won't do this because your app is the only one on the system. If Murphy has to he'll take the form of a rat that gnaws through your data cable.

On top of that, why throw an error if the file doesn't exist? Maybe this is a chance to make the file exist without hassling the user. Fail fast doesn't mean be pessimistic.

If the system is c:\MS\Windows and the user is typing /dev/nul you could be nice and parse their input and realize it's unusable. This is validation. It's the ONE thing constructors should do besides set instance variables. It's not about the current state of the file system. It's about whether your input is crap.

Validation can't involve talking to peripherals. In fact the thing you're validating must be full blown immutable or the test is a waste of time.

Fail fast should never overturn this. Fail fast argues that once attempting to use the file has caused an error you should get that exception going now, not later. But also, not before.

I deeply believe in fail fast myself. The idea is to help debugging devs by getting them as close to the cause of the issue as possible so they don't have to slog through file after file trying to figure out where a bad value came from.

However, file I/O is not something you should pretend you control. You don't. You're never going to. Say you test that the file exists and then try to use it. Well then Murphy will wait until your code is deployed on a critical system to delete, rename, or move that file between when you tested it and when you attempted to use it.

Every time you use a file, suspect that it might not be there and be ready for it. Nothing you do before hand absolves you of this. It's simply the reality of how I/O works. Don't pretend Murphy won't do this because your app is the only one on the system. If Murphy has to he'll take the form of a rat that gnaws through your data cable.

On top of that, why throw an error if the file doesn't exist? Maybe this is a chance to make the file exist without hassling the user. Fail fast doesn't mean be pessimistic.

If the system is c:\MS\Windows and the user is typing /dev/nul you could be nice and parse their input and realize it's unusable. This is validation. It's the ONE thing constructors should do besides set instance variables. It's not about the current state of the file system. It's about whether your input is crap.

Validation can't involve talking to peripherals. In fact the thing you're validating must be full blown immutable or the test is a waste of time.

Fail fast should never overturn this. Fail fast argues that once attempting to use the file has caused an error you should get that exception going now, not later. But also, not before.

I deeply believe in fail fast myself. The idea is to help debugging devs by getting them as close to the cause of the issue as possible so they don't have to slog through file after file trying to figure out where a bad value came from.

However, file I/O is not something you should pretend you control. You don't. You're never going to. Say you test that the file exists and then try to use it. Well then Murphy will wait until your code is deployed on a critical system to delete, rename, or move that file between when you tested it and when you attempted to use it.

Every time you use a file suspect that it might not be there and be ready for it. Nothing you do before hand absolves you of this. It's simply the reality of how I/O works. Don't pretend Murphy won't do this because your app is the only one on the system. If Murphy has to he'll take the form of a rat that gnaws through your data cable.

On top of that, why throw an error if the file doesn't exist? Maybe this is a chance to make the file exist without hassling the user. Fail fast doesn't mean be pessimistic.

It means if this is c:\MS\Windows and the user is typing /dev/nul you could be nice and parse this and realize it's unusable. This is validation. It's the ONE thing constructors should do besides set instance variables.

Validation can't involve talking to peripherals. In fact the thing you're validating must be full blown immutable or the test is a waste of time.

Fail fast should never overturn this. Fail fast argues that once attempting to use the file has caused an error you should get that exception going now, not later. But also, not before.

I deeply believe in fail fast myself. The idea is to help debugging devs by getting them as close to the cause of the issue as possible so they don't have to slog through file after file trying to figure out where a bad value came from.

However, file I/O is not something you should pretend you control. You don't. You're never going to. Say you test that the file exists and then try to use it. Well then Murphy will wait until your code is deployed on a critical system to delete, rename, or move that file between when you tested it and when you attempted to use it.

Every time you use a file suspect that it might not be there and be ready for it. Nothing you do before hand absolves you of this. It's simply the reality of how I/O works. Don't pretend Murphy won't do this because your app is the only one on the system. If Murphy has to he'll take the form of a rat that gnaws through your data cable.

On top of that, why throw an error if the file doesn't exist? Maybe this is a chance to make the file exist without hassling the user. Fail fast doesn't mean be pessimistic.

If the system is c:\MS\Windows and the user is typing /dev/nul you could be nice and parse their input and realize it's unusable. This is validation. It's the ONE thing constructors should do besides set instance variables. It's not about the current state of the file system. It's about whether your input is crap.

Validation can't involve talking to peripherals. In fact the thing you're validating must be full blown immutable or the test is a waste of time.

Fail fast should never overturn this. Fail fast argues that once attempting to use the file has caused an error you should get that exception going now, not later. But also, not before.