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

В целом согласен, однако последний аргумент не совсем удачен.

IT>Но это ещё не всё.

IT>AccountDataAccessor. Мой код.

IT>

IT>public decimal GetBalance(string accountNumber)
IT>{
IT>  return (decimal)ExecuteScalarSp("GetBalance", accountNumber);
IT>}
  
IT>

IT>Твой вариант.

IT>

IT>public bool GetBalance(string accountNumber, out newBalance, ref Errors err)
IT>{
IT>  // oops!!! А ExecuteScalarSp параметра Errors не поддерживает.
IT>  // Ну дятлы её какие-то писали, не додумались до такой классной идее.
IT>  //
IT>  ///////////return (decimal)ExecuteScalarSp("GetBalance", accountNumber);
IT>}

IT>// остальные упсы поскипаны.
IT>

IT>В случае со "стандартной" ExecuteScalarSp, чтобы сохранить лицо, тебе скорее всего придётся написать длиннючий switch на все возможные коды возврата и подобрать к ним более менее вменяемые сообщения.

Насколько я понимаю, проблемы возникаеют когда встречаются два взаимоисключающий подхода (обработки исключений, в данном случае). Если бы стиль ref-out был общепринятым, то и ExecuteЧего-То-ТамSp его бы тоже поддерживал. И в этом случае пришлось бы написать длиннючий switch для того, чтобы Errors err преобразовать в исключения.

IT>Да, кстати, использование ref и out параметров считается признаком плохого дизайна. FxCop на это заявляет "Consider a design that does not require that 'parameter_name' be an out parameter".

Полагаю, FxCop не знает об использования стиля ref-out как альтернативы исключениям. И если ref-out плох, то отнюдь не потому, что FxCop его не понимает. Если бы более удобного подхода обработки исключений не было, чем ref-out, то и FxCop на него бы не ругался.