なにを聞きたいのか良くわかりませんが・・・

企業内のプログラマーの方なら、そのプログラミングをさせているＳＥの詳細設計
段階での問題だと思います

個人趣味的な自作設計＆プログラミングならそせぞれが持つポリシーの問題です

つまりＯＳにまかせ、ソースは簡潔に追えることを良いと評価する人もいるし
すべてをエラーチェックし、独自のメッセージ処理をしプログラムソースは
どんなコーディングをしていようとも実行時のメッセージが親切丁寧なもの
見た目がよければよいと評価する人もいる

＞プログラムの質が悪いと思えてしまうのです。
これを論議してほしいのならこんなとこでだめですか

それともここまで　すべて　はずしていて　

＞FindFirstFile()
について聞きたいのでしょうか？

　関数が失敗するというふうに考えるからいけないのでは？

　例えば、１０個の配列から検索するプログラムを作成すると、データが無い場合は
データが無いことを伝えなければならない。
　このため、戻り値でコールした側に知らせる必要がある。

　これと同じことだと思いますが。

http://www.ziyu.net/~rent/tree/wforum.cgi?id=C_lan&mode=all_read&no=1160&page=0

>関数が失敗するというふうに考えるからいけないのでは？
同感です。

>第1引数で指定したパスが存在するかしないかというエラーチェックは
>FindFirstFile() に任せた方が簡単だから、その方がいいんでしょうか？
その方がいいと思います。最も単純だと思うからです。

(1) FindFirstFile()の返値を確認する
(2) FindFirstFile()以前にパス存在を確認する

は何れも同じような事です。それなら単純な方を取る方が合理的です。
従って、理由が無い限り(1)を取った方がいいと思います。

API の呼び出しの結果、失敗する原因が一つとは限りません
ですから、API が失敗したことを戻り値で報告して、原因は GetLastError() で
取得するという設計に問題があるとは思えませんけど

>API の呼び出しの結果、失敗する原因が一つとは限りません
>ですから、API が失敗したことを戻り値で報告して、原因は GetLastError() で
>取得するという設計に問題があるとは思えませんけど
仰る通りですね。
但し、FindFirstFile()がINVALID_HANDLE_VALUEを返す原因の殆どは「ファイルが無い」
事です。(私はそれ以外見た事がありません)この為、
「エラー判別の厳密性より単純さを重視したコードの方が得する確率が高い」
と判断しました。従って前述のような意見を述べました。
Sigeさんが最終判断をする為の参考になれば幸いですね。

> そうすると、FindFirstFile() が失敗するわけで、失敗という結果が
> プログラムの質が悪いと思えてしまうのです。

...ここがわからん。失敗したことを検出し、それに応じた処理を
おこなっているなら、プログラムの質が悪いなんて誰が責めましょうや。

char filename[64]; // ユーザが入力したファイル名
FILE* fp = fopen(filename, r);
if ( fp == NULL ) {
/* オープン失敗 */
return 1;
}

...このプログラムは質が悪いのでしょうか?

それに、FindFirstFile(...) は指定されたパスにマッチする
ファイルの情報を入手するのがお仕事です。パスにマッチするファイル
が見つからないのだから、その情報を入手できなかったのです。
意味的にはファイルオープンの失敗と同じです。

fopenの前にファイルの存在を確認しますか? やらんと思うぞ大抵のヒトは。