Здесь есть интересный пост об этом, в отношении потока управления кросс-приложениями.
Хорошо, недавно я столкнулся с интересной проблемой. Генерация n-го значения в потенциально (практически) бесконечной рекурсивной последовательности. Этот конкретный алгоритм будет находиться по меньшей мере в 10-15 ссылках на стопки в той точке, в которой он преуспевает. Моя первая мысль заключалась в том, чтобы бросить SuccessException, который выглядел примерно так (С#):
class SuccessException : Exception
{
public string Value
{ get; set; }
public SuccessException(string value)
: base()
{
Value = value;
}
}
Затем сделайте что-то вроде этого:
try
{
Walk_r(tree);
}
catch (SuccessException ex)
{
result = ex.Value;
}
Затем мои мысли побрели сюда, где я снова и снова слышал, чтобы никогда не использовать Исключения для управления потоком. Есть ли оправдание? И как бы вы структурировали что-то вроде этого, если бы вы его реализовали?
В этом случае я бы посмотрел на ваш метод Walk_r, у вас должно быть что-то, возвращающее значение, бросая исключение, чтобы указать на успех, НЕ является обычной практикой и, как минимум, будет ОЧЕНЬ смущать любого, кто видит код. Не говоря уже об издержках, связанных с исключениями.
walk_r должен просто вернуть значение при его ударе. Это довольно стандартный пример рекурсии. Единственная потенциальная проблема, которую я вижу, заключается в том, что вы сказали, что она потенциально бесконечна, и ее нужно будет компенсировать в коде walk_r, сохраняя подсчет глубины рекурсии и останавливаясь при некотором максимальном значении.
Исключение действительно делает кодирование очень странным, поскольку вызов метода теперь выдает исключение для возврата значения вместо простого возврата "обычно".
try
{
Walk_r(tree);
}
catch (SuccessException ex)
{
result = ex.Value;
}
становится
result = Walk_r(tree);
Не очень хорошая идея генерировать исключения как часть алгоритма, особенно в .net. В некоторых языках/платформах исключения довольно эффективны при броске, и обычно они возникают, когда итерируемый становится исчерпанным, например.
Почему бы просто не вернуть полученное значение? Если он вообще что-то возвращает, предположите, что он успешный. Если ему не удается вернуть значение, значит это означает, что цикл завершился неудачно.
Если вы должны вернуть сбой, тогда я рекомендую вам исключить исключение.
Проблема с использованием исключений заключается в том, что tey (в большой схеме вещей) очень неэффективны и медленны. Разумеется, было бы легко иметь условие if в рекурсивной функции, чтобы просто возвращать по мере необходимости. Честно говоря, с объемом памяти на современном ПК это маловероятно (хотя и невозможно), что вы получите переполнение стека с небольшим количеством рекурсивных вызовов (< 100).
Если стек является реальной проблемой, тогда может возникнуть необходимость в "креативе" и реализации стратегии поиска с ограниченным доступом, позволяющей функции возвращаться из рекурсии и перезапускать поиск с последней (самой глубокой) node.
Подводя итог: Исключения должны использоваться только в исключительных обстоятельствах, успех вызова функции, который я не считаю квалифицированным как таковой.
Использование исключений в обычном программном потоке в моей книге - одна из худших практик. Рассмотрим бедного сока, который охотится за проглоченными исключениями и запускает отладчик, который останавливается всякий раз, когда происходит исключение. Этот чувак теперь злится... и у него есть топор.: P
Я собираюсь сыграть здесь адвоката дьявола и сказать палку, за исключением того, чтобы указать успех. Это может быть дорого бросить/поймать, но это может быть незначительным по сравнению со стоимостью самого поиска и, возможно, менее запутанным, чем ранний выход из метода.