Правильный способ передачи ошибок обратно в вызывающий код

Что-то вроде:

public void Connect()
{
  try
  {
    //code here to look-up the connection details
    if(!ValidateConnectionDetails(details))
      throw new InvalidOperationException("The connection details are not valid.");
    //code here to establish the connection
    if(SomeTestThatShowsWereNotHappyWithTheConnection())
      throw new Exception("The connection is bad, for some reason");
  }
  catch(SocketException se)
  {
    //We'd only have this block if a socket exception is possible. We might just allow it to pass on up.
      throw; // User now gets the exception we got, exactly.
    //We might re-throw the error, but from here so the stack-trace goes to here rather than the innards of this method:
      throw se;
    //Most usefully we might throw a new exception that contains this as an inner exception:
      throw new Exception("Connecting failed", se);
    //Or even better, we might throw a more well-defined exception, that relates to this operation more specifically, with or without the inner exception, depending on whether that is likely to be useful:
      throw new ConnectionException("Some message, or maybe just a default is defined in the constructor");
    //OR:
      throw new ConnectionException("Some message, or maybe just a default is defined in the constructor", se);
  }
  catch(Exception ex)
  {
    //If we get to an exception ourselves that isn't of a particular type we're expecting, we probably shouldn't catch it at all. We might though want to note the exception before re-throwing it, or throw a more specific connection with this as an inner-exception:
    Log(ex);
    throw;
  }
}

Поскольку вы больше не возвращаете значение для указания успеха, вы также можете вернуть объект, который представляет созданное соединение:

public ConnectionObject Connect()
{
   // Much as above, but returning the object before the end of the 'try'.
}

Возвращаемые значения, представляющие отказ, должны выполняться только в том случае, если это может произойти, и то, что вы ожидаете, что вызывающий код сможет разумно реагировать на право в точке вызова. Это не так, вероятно, с кодом для подключения, так как вызывающий код может быть кодом, который, например, соединяется, а затем выполняет операцию, а вызов кода, в свою очередь, должен быть обнаружен исключение (будь то здесь или последующая операция) это код, который в конечном счете заботится о неудаче.

В последнем случае возвращение значения, указывающего на отказ, имеет гораздо больший смысл. Тем не менее, я бы, вероятно, по-прежнему рассматривал исключение, потому что он может инкапсулировать больше информации, использоваться кодерами в обычном способе, которым они используют другие методы.NET, и потому что код вызова, вероятно, не написан, думая "попытайтесь получить соединение а затем, если это сработает... ", он написал мышление" получить связь, а затем... ", причем ошибка была именно такой; ошибка. (Для сравнения, такой метод, как int.TryParse(), должен ответить на вопрос: "Эта строка представляет собой целое число, и если да, то что это такое?", Где метод int.Parse() отвечает на вопрос "что такое целое число в эту строку? ", где не было целого числа, являющегося условием ошибки).

Подумать об этом по-другому. Вы используете веб-браузер для просмотра веб-страниц или используете его, чтобы попытаться просмотреть веб-страницы? Ваше интернет-соединение может умереть на вас, не позволяя вам продолжать читать эти ответы, но вы бы подумали, что проблема в том, что вы пытались сделать.