Есть ли разница между

function ()
{
  A obj = new A();
  try
  {
    return obj;
  }
  catch
  {
    return obj;
  } 
}


function ()
{
  A obj = new A();
  try
  {

  }
  catch
  {
    return obj;
  }
  return obj;
}

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

P>Есть ли разница между

P>

P>function ()
P>{
P>  A obj = new A();
P>  try
P>  {
P>  }
P>  catch
P>  {
P>  }
P>  return obj;
P>}
P>

Тогда уж так.

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

P>Есть ли разница между

На практике нет. Для больших методов оба плохи. Например, ниже может затаиться finally, человек, читающий код, может его не заметить.
Для мелких первый вариант, пожалуй будет более читабельным.

Я обычно предпочитаю писать код так, чтобы в коде после валидации аргументов был только один return, в конце метода. Во-первых, при чтении увидят весь метод целиком, во-вторых, если логика в return усложнится, её не надо будет копипастить, в-третьих, return в произвольных местах здорово усложняет читаемость, особенно если catch-ей несколько.

Конечно, можно придумать исключения типа

switch (x)
{
  case CaseA: return A(x);
  case CaseB: return B(x);
  case CaseC: return C(x);
  default: throw ...
}

но на общий принцип они никак не влияют.

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

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

P>>Есть ли разница между

S>На практике нет. Для больших методов оба плохи. Например, ниже может затаиться finally, человек, читающий код, может его не заметить.
S>Для мелких первый вариант, пожалуй будет более читабельным.

S>Я обычно предпочитаю писать код так, чтобы в коде после валидации аргументов был только один return, в конце метода.

вот из-за этого и вопрос возник.
а что вы возвращаете если перед работой с базой надо сделать кое-какие проверки, как на null, непустой массив передан, так и по логике и если что-то не удовлетворяет логике сказать клиенту и работу с базой не осуществлять?

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

P>а что вы возвращаете если перед работой с базой надо сделать кое-какие проверки, как на null, непустой массив передан, так и по логике и если что-то не удовлетворяет логике сказать клиенту и работу с базой не осуществлять?

Для таких случаев используют исключения, по крайней мере в дотнете и в яве.

Если ситуация "не смог соединиться" является нормальной и вызывающий код знает, как её обработать, рядом заводят метод с префиксом Try (Connect()/TryConnect()), который возвращает null на случай "не шмогла".

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

S>Я обычно предпочитаю писать код так, чтобы в коде после валидации аргументов был только один return, в конце метода. Во-первых, при чтении увидят весь метод целиком, во-вторых, если логика в return усложнится, её не надо будет копипастить, в-третьих, return в произвольных местах здорово усложняет читаемость, особенно если catch-ей несколько.

Во времена оные был полезный совет : у функции (тогда еще не было классов) должен быть один вход и один выход.

Более одного входа сейчас практически никакие приличные языки не допускают (в Фортране есть).
А вот вторым правилом многие пренебрегают. А зря.

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

PD>у функции (тогда еще не было классов) должен быть один вход и один выход.
PD>правилом многие пренебрегают. А зря.

Согласен целиком и полностью. Но этож рсдн, слово мимо — вэлкам в холивар Один пример с свитчем я привёл выше, ну и вариант с "срезанием углов", куда без него:

// псевдокод
bool IsValid(SomeObject x)
{
  if (x == null) return false;

  if (cache.Contains(x)) return true;

  if (x.State == State.Raw) return false;

  // тут собственно проверка
}

в остальном — да. Ситуация, когда выполнение метода прерывается на самом интересном месте обычно значит, что у нас косяк в понимании задачи.

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

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

S>>Я обычно предпочитаю писать код так, чтобы в коде после валидации аргументов был только один return, в конце метода. Во-первых, при чтении увидят весь метод целиком, во-вторых, если логика в return усложнится, её не надо будет копипастить, в-третьих, return в произвольных местах здорово усложняет читаемость, особенно если catch-ей несколько.

PD>Во времена оные был полезный совет : у функции (тогда еще не было классов) должен быть один вход и один выход.

я тоже когда то так писал.
но вот вам веб. есть вызов веб-сервиса через аджакс и передача массива json.
результатом клиенту может быть что угодно, от пустого массива, которого должно быть или передачи null до того, что часть данных удалось удалить, а часть уже кто-то удалил.
Как вы предлагаете клиенту ответ формировать?

String GetResult(string[] arr)
{

String result;


}

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

S>На практике нет. Для больших методов оба плохи. Например, ниже может затаиться finally, человек, читающий код, может его не заметить.

большие методы сам по себе плохи, их ничего не спасёт (никакая практика).
обычно большие методы можно разделить как минимум на 3 — 4 метода поменьше размером.

Здравствуйте, Sinix, Вы писали:
....ну и вариант с "срезанием углов", куда без него:
S>

S>// псевдокод
S>bool IsValid(SomeObject x)
S>{
S>  if (x == null) return false;

S>  if (cache.Contains(x)) return true;

S>  if (x.State == State.Raw) return false;

S>  // тут собственно проверка
S>}
S>

А что в этом плохого, в таком подходе? Или я не уловил иронии!?!

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


C>А что в этом плохого, в таком подходе? Или я не уловил иронии!?!

Упс
Конечно ничего плохого, я его привёл как пример, когда правило одного return только вредит. Выше по ветки был ещё один пример, с свитчем.

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

P>но вот вам веб. есть вызов веб-сервиса через аджакс и передача массива json.
P>результатом клиенту может быть что угодно, от пустого массива, которого должно быть или передачи null до того, что часть данных удалось удалить, а часть уже кто-то удалил.
P>Как вы предлагаете клиенту ответ формировать?

С AJAX я не работаю, поэтому, возможно, что-то не учту. Но ИМХО в любом случае можно преобразовать функцию к такому виду, чтобы return был в конце.

if(условие) return что_то

заменим на

if(!условие) // все, что было после предыдущего оператора
else result = что_то;

Конечно, при этом могут получиться if-else чудовищной вложеннности.

Впрочем, я и сам этими множественными return грешу. Понятнее. Хоть и не соответствует неким высшим принципам.

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

PD>Конечно, при этом могут получиться if-else чудовищной вложеннности.

И это что, ты считаешь нормальным?

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

AVK>И это что, ты считаешь нормальным?

Да, в общем-то, нет, не считаю.
Я и сам эти множественные return пишу. Морально страдаю , но все же пишу.
Кстати, твой любимый рефакторинг может сделать все это более или менее удобочитаемым.

P.S. А тебе действительно интересно, что я об этом думаю, или же появилось желание в очередной раз устроить бессмысленный и беспощадный флейм ? Если второе — давай лучше сразу и закончим, ибо надоело.

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

PD>Я и сам эти множественные return пишу. Морально страдаю , но все же пишу.

Так может чего с моральными принципами не так, если они не пользу приносят, а исключительно страдание?

PD>Кстати, твой любимый рефакторинг может сделать все это более или менее удобочитаемым.

Что, вложенные if? Каким образом? Преобразовав их в невложенные?

PD>Если второе — давай лучше сразу и закончим, ибо надоело.

Так не пиши негодных рекомедаций.

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

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

S>>На практике нет. Для больших методов оба плохи. Например, ниже может затаиться finally, человек, читающий код, может его не заметить.

Ф>большие методы сам по себе плохи, их ничего не спасёт (никакая практика).
Ф>обычно большие методы можно разделить как минимум на 3 — 4 метода поменьше размером.

далеко не всегда. Большие функцие же не просто так большие. Обычно в больших функциях создается десятка три локальных переменных, которые используются на протяжении всей функции. И как ты ее будешь делить? Передавать всё в части параметрами? Предвижу возражение — не могут все части функции пользоваться всеми 30 пременными сразу. Согласен, не могут, каждая часть использует свое подмножество — только вот эти подмножества для разных частей вступают в сложно-подчиненные отношения и очень редко когда факторизуются. Упаковывать в структуру? тогда с областью видимости беда будет (порядок конструирования/убивания весь лесом пойдет). Всю функцию делать классом? а разные ее части — разными закрытыми методами? и чтоб наружу только один открытый метод-оператор-вызова-функции? Опять же, те же проблемы насчет видимости.
В общем, по моему опыту, длинные функции, которые можно без геморроя разделить на функции поменьше — они длинные просто от лени, а не потому что задача требует.

You will always get what you always got
  If you always do  what you always did

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

J>Здравствуйте, Философ, Вы писали:

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

S>>>На практике нет. Для больших методов оба плохи. Например, ниже может затаиться finally, человек, читающий код, может его не заметить.

Ф>>большие методы сам по себе плохи, их ничего не спасёт (никакая практика).
Ф>>обычно большие методы можно разделить как минимум на 3 — 4 метода поменьше размером.

J>далеко не всегда. Большие функцие же не просто так большие. Обычно в больших функциях создается десятка три локальных переменных, которые используются на протяжении всей функции. И как ты ее будешь делить? Передавать всё в части параметрами? Предвижу возражение — не могут все части функции пользоваться всеми 30 пременными сразу. Согласен, не могут, каждая часть использует свое подмножество — только вот эти подмножества для разных частей вступают в сложно-подчиненные отношения и очень редко когда факторизуются. Упаковывать в структуру? тогда с областью видимости беда будет (порядок конструирования/убивания весь лесом пойдет). Всю функцию делать классом? а разные ее части — разными закрытыми методами? и чтоб наружу только один открытый метод-оператор-вызова-функции? Опять же, те же проблемы насчет видимости.


а пример можно по выделенному?

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

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

J>>далеко не всегда. Большие функцие же не просто так большие. Обычно в больших функциях создается десятка три локальных переменных, которые используются на протяжении всей функции. И как ты ее будешь делить? Передавать всё в части параметрами? Предвижу возражение — не могут все части функции пользоваться всеми 30 пременными сразу. Согласен, не могут, каждая часть использует свое подмножество — только вот эти подмножества для разных частей вступают в сложно-подчиненные отношения и очень редко когда факторизуются. Упаковывать в структуру? тогда с областью видимости беда будет (порядок конструирования/убивания весь лесом пойдет). Всю функцию делать классом? а разные ее части — разными закрытыми методами? и чтоб наружу только один открытый метод-оператор-вызова-функции? Опять же, те же проблемы насчет видимости.


P>а пример можно по выделенному?
Ну обычно ты пишешь

A a;
// какой-то код
B b(a);
// какой-то код
{
  C c(a,b);
  // какой-то код
} // тут с умирает, зовется деструктор
D d(b);
// какой-то код

Если попробуешь закомментированные куски кода убрать в функции, то a,b,c,d придется передавать внутрь честно, потому что упаковка их в структуру типа

struct local_params{
  A a;
  B b;
  C c;
  D d;
};

нарушит все взаимозависимости создания и эффекты деструкции (ну или, как вариант, придется все хранить через умные указатели — хотя в оригинале все замечательно сидит на стеке)

You will always get what you always got
  If you always do  what you always did

J>нарушит все взаимозависимости создания и эффекты деструкции (ну или, как вариант, придется все хранить через умные указатели — хотя в оригинале все замечательно сидит на стеке)

Передача по ссылке в С++ ничего не нарушит. Кроме того, разделение на несколько блоков может включать некий рефакторинг всей функции.

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


J>>нарушит все взаимозависимости создания и эффекты деструкции (ну или, как вариант, придется все хранить через умные указатели — хотя в оригинале все замечательно сидит на стеке)

C> Передача по ссылке в С++ ничего не нарушит. Кроме того, разделение на несколько блоков может включать некий рефакторинг всей функции.

Это был ответ на мое сообщение в целом или только на вырванную из контекста фразу выше?

You will always get what you always got
  If you always do  what you always did