[lelanthran]

> (i.e., file might be missing, remember to check)

There is no point to performing an existence check of a file before opening it, because regardless of whether the check returns true or not, you still have to handle the error cases from `FileOpen`, because the file might have disappeared[1] between the call to `FileExists` and the subsequent `FileOpen`.

If you have to always handle a return of `FileDoesntExist` when performing `FileOpen`, there's literally no point in checking beforehand.

[1] Even if it didn't, there's a myriad of other errors that can happen when opening the file, such as `PermissionDenied`, `FileLocked`, `IsDirectory`, etc ... and you need to handle every single one of them! You don't necessarily have to handle them individually, you can handle them as a group like in the pseudocode below, but it still makes the call to `FileExists` pointless.

    if (err == FileOpen(someFileName)) {
        handleFileError (err);
    }

[sirwhinesalot]

I never suggested calling FileExists separately, no idea where you got that from. The article explicitly refers to modeling the codomain of the function accurately, in this case something like Result<File, FileError>

[lelanthran]

> I never suggested calling FileExists separately, no idea where you got that from.

I got it from this:

>>> (i.e., file might be missing, remember to check)

What did you mean by "remember to check"?

[sirwhinesalot]

You can't use the Result sum type without first checking if it is the valid case or the error case. The type system won't let you forget to check. it's reminding you with red squiggles in your IDE. This is a good feature to have.