Здравствуйте, AlexRK, Вы писали:

F>> Если под процессом, понимается изолированный юзер-спейс, то — это один из наихудших вариантов, особенно для исходного примера. Код собственно говоря хочет работать с документом (state), используя stateful API, а не с набором сообщений (непосредственно или через прокси — это не так важно).
ARK>Да, именно изолированный юзерспейс. В Singularity каналы предоставляют stateful API. Только вот использовать его "как попало" нельзя — для канала задаются четкие правила — что, когда и откуда идет, обойти которые нельзя (компилятор запрещает). Ошибки являются частью контракта канала.
1. Research проекты это хорошо. Я даже за, когда я его смотрел, мне нравилось. Практической же пользы, для нас, программистов наших дней — толку от него вообще никакого.
2. Как иронично, что когда мы обсуждаем error code vs exceptions — показывать ресерч платформу, где есть exceptions.
3. Коммуникационные каналы сразу станут мусором, как только перестанет быть возможным вложить туда то, что хочется.

F>> Но вообще-то в исходном примере была простая лямбда.
ARK>Ну, я в контексте плагинов чуть развил тему.
Отлично. Независимые куски, процессы — они падают, а IPC отваливается. Это вовлекает необходимость обработки ошибок.

TReply SyncRequest<TRequest, TReply>(TRequest request);

Вот сигнатура метода. Этот метод, может упасть: на сериализации сообщения, на передаче сообщения, на десериализации сообщения. При чём ошибка передачи сегодня одна — завтра другая. Сегодня мы используем WCF over pipe, а потом когда задолбались с тем, что оно нихрена не работает — изменили канал, на собственный (с верой что оно будет работать лучше). Так вот — методу SyncRequest — совершенно пофигу на 3 вещи, и даже не знает о:
1. Реализации сериализатора.
2. Реализации канала.
3. Реализации десериализатора.
При этом внешний (вызывающий) код, на котором лежит отвественность обработки ошибки — с исключениями — получает более-менее внятную диагностику, безо всякого протаскивания кодов ошибок в сигнатуры.

А вот другой метод:

void PostAsync<TMessage>(TMessage request);

Данный метод никогда не валится, потому что складывает сообщения в очереди. Но, исключения всё равно могут пораждаться при отсылке инфраструктурой. Если же я залогирую безликие коды ошибок — это существенно усложнит процесс.
Более того, никто не мешает включить дебаг/трейс (всё есстественно в релизной конфигурации), в .NET в частности, и снять стэк-трэйс при постановки сообщения в очередь, если нужно связать сообщение с местом посылки. И то, это всё ещё будет очень безлико.

И на фоне таких, богатых возможностей — вы предлагаете использовать обыкновенную лапшу с кодом возврата.

Я не давно заглянул в код Add-In COM Shim — и увидел сплошную лапшу и макрос навроде:

#define SUCCESS(x) if (!(x)) goto error;

.
Это просто ужасно. Это нормально для небольшого C/C++ кода. Это абсолютно ужасно для нового, якобы безопасного языка.
Sinclair, вот и исключениями, то не очень доволен — но лучше уж исключения, чем уг с протаскиванием кодов ошибок.

Тем более, что в 99% случаев, на исключения всем параллельно. Вы читаете файл — вам пофигу, что не так. Вы его хотели прочитать — вы его не прочитали. Нет файла, или это проблема с доступом, или вообще не дошло до этого дела — разруливать конкретные ситуации надо, но не так что бы очень уж часто. Важнее знать, что мы сделали или нет, то что хотели.


F>> Во всех существующих ОС такой подход как раз работает, и это единственный путь выполнить что-нибудь в "песочнице". Проблема в том, что это довольно дорого с любой сточки зрения, но в осмысленных случаях — он успешно используется.
ARK>Понятно, что работает. Всё работает. И виндовс работает, и линупс работает, и QNX тоже. Только вот как, сколько в коде ошибок и насколько он устойчив — вопрос риторический.
Windows, Linux, OSX — имеют отличные стабильные ядра, и собственно говоря пока не предвидится, что бы их кто-нибудь превзошел.
Ошибки безусловно есть везде, но и мир на месте не стоит. А Singularity всё равно содержит какое-то (5%?) количество нативного кода. Увы. Докажете его безопасность?