AS>>Хочется формальных критериев, когда надо только исключения, когда только результат, когда нужно, например, вот такое раздвонение интерфейса.

J>Имхо, нету таких формальных критериев.
J>Все зависит от пользователя: для одного неудача — штатная ситуация, а для другого — фатальная ошибка.

J>Например, должна ли бросать функция открытия файла, если файл не найден?

Вот, вот, примерно это.

J>Если у тебя список файлов, и тебе нужно попробовать их все по порядку и использовать первый нашедшийся, то неудача с одним файлом — это штатный эпизод перебора файлов, а фатальная ошибка — это если вообще ни одного файла нет.

Лучше пример с неименованным мьютексом без секьюрити Там менее очевидно чем с файлом (тем более для файла есть пример — mfc, где как раз сделано более-менее в плане проектирования нормально).

А если с файлом — тогда лучше рассмотреть метод Read или Write. По моим ощущениям, напрмер, в данном случае как раз можно найти некий баланс в виде result code (if success or eof) + exception if failure. Т.е. в 99% юзекейсов покрывается. Так сделано в mfc и, похоже, это довольно неплохой дизайн в таких случаях, хотя раньше я думал иначе . Вот хочется примерно таких рекомендаций, дабы разработчику не надо было думать, что в каких случаях делать, да и все проще, если играть по правилам.

J>А если у тебя всего лишь одно имя файла, то невозможность его открыть — это фатальная ошибка.

С файлами все вообще сложнее — надо делать двухуровневое конструировение, либо делать одноуровневое + порождающую фабрику. Меня больше, повторюсь, интересуют пограничные случаи типа неименованного мьютекса.

J>Так что правильный путь, имхо — это дать возможность пользователю самому решить, что ему нужно, например, как делает boost.asio (можно и по-другому делать).

Но, имхо, не для каждого интерфейса. Либо делать 2 разных интерфейса с возможность move-upgrade одного в другой...
Вот этого бы не хотелось, на самом деле.