использование исключений в неошибочных целях

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

Обычно нет, нет. ASP.NET использует это для Response.Redirect - фактически прерывая поток, затем перехватывая исключение и сбрасывая его. Это очень неприятно, но оно действительно позволяет вам в основном "выйти" из запроса без того, чтобы каждый уровень стека знал, что он должен немедленно вернуться.

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

Как видно из названия, исключения следует использовать только в исключительных случаях. Я бы не стал использовать его для управления случаями, не связанными с ошибками.

Нет.

Исключения следует использовать только в исключительных ситуациях (как следует из названия). Это означает: ошибки.

• «Я не могу найти этот файл». - Исключение!
• «Я не могу делить на 0». - Исключение!
• «У меня нет памяти». - Исключение!
• «Результат 2,5.» - Без исключения!

Это очень сомнительная практика. Если вы все равно считаете, что это лучший вариант для вашей ситуации, обязательно задокументируйте и тщательно прокомментируйте его, чтобы снизить WTF / m .

Я считаю, что иногда исключения полезны для построения DSL s. Я знаю, это звучит странно, но поскольку во многих языках нет функций, которые есть в Ruby (ключевое слово return необязательно, потому что возвращается результат последнего вычисленного выражения), мы используем то, что можем.

Например, я недавно пытался создать небольшую среду тестирования JavaScript, и мне нужен был способ, чтобы пользователи инфраструктуры могли сказать:

skip();
pending("pending message");
fail("failure message");

вместо:

return skip();
return pending("pending message");
return fail("failure message");

Эти функции будут библиотечными функциями, которые генерируют исключения, например, исключение SkipTest. Единственное рекомендуемое место для их использования - это методы тестирования. Эти методы тестирования всегда выполняются в блоке try / catch, где обрабатывается каждый тип исключения, и, в зависимости от исключения, инфраструктура выполняет соответствующий шаг.

Это пример, в котором я ' Мы использовали исключения для потока управления.

Вот небольшой пример:

$.it("should offer means to explicitly mark a spec as failed", function() {
    $.fail("this spec must fail");
});

Нет.

Как правило, система предназначена для ускорения неисключительных случаев при одновременном принятии в исключительных случаях снижается производительность. Таким образом, генерирование / перехват множества исключений будет происходить медленнее, чем обычные конструкции.

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

Ранее я успешно использовал код из лаборатории обработки изображений в проекте кода. (обновление: вот библиотека , которую она использует)

Кристиан Граус (Christian Graus) также написал целую серию по обработке изображений GDI, которую я счел полезной (и имеет перечисленные выше эффекты для возможностей фильтрации).

Если необходимо добавить объект nil в коллекцию, используйте класс NSNull :

Класс NSNull определяет одиночный объект, используемый для представления нулевых значений в объектах коллекции (которые не разрешают значения nil).

Предполагается, что «array» имеет тип NSMuterArray:

....
[array addObject:[NSNumber numberWithInt:2];
[array addObject:@"string"];
[array addObject:[NSNull null]];

В решателе sudoku, который я написал, создается исключение в случае, если головоломка решена .

Основная функция поиска, частный метод, опускается в дерево поиска, совершая рекурсивные вызовы. нормальный случай - это неспособность решить головоломку, что приводит только к нормальному возврату вызывающему абоненту; исключительный случай - это успех в решении головоломки, и в этом случае мы «бросаем (решаем)» весь путь к пункту улова в публичном методе.

Что-то подобное является известной идиомой в схеме, использующей вызов/cc. Я подражал этому в моей программе C++.

Я был бы рад услышать чьи-либо мнения о таком подходе.