エラーを検出するにはexcludefdsが必要であると考えられることもありますが、それは誤解です。エラーはreadfdsでフラグが付けられます。POSIXはそれを必要としますが（そしてパラメータerrorfdsを呼び出すことさえあります）、エラーがexceptfdsでもフラグ付けされるかどうかはOSに依存します。実際、このパラメーターが必要になるのは、例外的な条件を気にする場合だけですが、それらを検出する必要があることはめったにありません。
例外条件と見なされるものはファイル記述子の種類によって異なりますが、最も一般的な使用法はrecv()、MSG_OOBフラグを使用して帯域外データを読み取ることができることを示すTCPソケットです。ただし、TCP帯域外データには多くの癖があり（たとえば、1バイトのみが未処理である可能性があります）、その結果、ほとんど使用されません。
最近のLinuxカーネルでは、 fdsを除いて、特定のsysfs属性がいつ変更されたかを検出するために使用できます。属性の現在の値は、の下の適切なファイルを読み取ることで読み取ることができ、ファイル記述子の/sysaは、属性が変更されたときにexceptfdsにフラグを立てます。ただし、これは現在、一部の属性とマウントの変更（）に対してのみ機能します。select()/proc/mounts
また、一部のデバイスドライバーは、exceptfdsを使用して特定のデバイス固有の条件にフラグを立てます。
そうです、ファイル記述子で参照しているデバイスのタイプによって異なります。したがって、ソケット、FIFO、シリアルポートなどでは異なります...
read() のマニュアル ページを参照してください。下部 (少なくとも OS X では) には、さまざまなデバイスで発生する可能性のあるさまざまなエラーが一覧表示されます。write() も同様です。
ソケット、FIFO、およびその他の IPC メカニズムについては、Unix Network Programming、Volume 1 および 2 を調べます。IIRC には、さまざまなエラー条件で予想されるエラー番号の種類が記載されています。
FIFO を使用して、この道を 1 回歩きました。最終的に、プロデューサーとコンシューマーが FIFO の両端と対話できるすべての方法についてブレインストーミングを行い、それらの状況ごとにテスト ケースを作成しました。これは、さまざまなエラー状態をすべて発見するための (面倒ではありますが) 良い方法でした。私は多くのことを学びましたが、最終的にはコードが機能するようになりました。