Полное использование 'если' операторы или блоки 'попытки/выгоды'?

Вы можете установить уровень регистрации искрового регистратора непосредственно из sparkContext. Чтобы уменьшить многословность Spark, вы должны установить уровень ERROR, чтобы спарк мог записывать журнал только в случае ошибки.

val session =  SparkSession.builder().appName("appName").master("local[*]").getOrCreate()
session.sparkContext.setLogLevel("ERROR")
9
задан Daddy Warbox 30 November 2008 в 16:13
поделиться

8 ответов

7
ответ дан 4 December 2019 в 11:08
поделиться

if блоки немного быстрее; если Вы не испытываете необходимость в дюжине из них, они - лучшая идея, чем try/catches. Исключения должны быть исключительными, не каждый раз выполнения кода. Я использую Исключения для редких случаев как разъединения сервера (даже при том, что они происходят несколько раз каждый день), и if блоки для любой из моих управляемых переменных.

5
ответ дан 4 December 2019 в 11:08
поделиться

Независимо от того, какой код Вы пишете, Вы закончите тем, что использовали обоих. Я не могу говорить за Среду выполнения Java, но на времени выполнения.NET существует хит производительности, связанный с использованием блоков try-catch. В результате я пытаюсь использовать их только в областях, где у меня есть ясный способ обработать исключение, однажды пойманное (даже если оно просто регистрирует существование проблемы).

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

3
ответ дан 4 December 2019 в 11:08
поделиться

Я думаю, лучше ли операторы. Вы не можете окружить каждую строку кода попыткой.. выгода (хорошо Вы можете, но Вы не должны делать этого). Можно окружить блок кода выгодой попытки, но не каждой строкой.

И исключения замедляют вещи.

2
ответ дан 4 December 2019 в 11:08
поделиться

Мои 2 пункта: Используя попытку/выгоду является лучшим:

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

По моему опыту, использование if-conditional-logic делает более трудным отличить обработку ошибок от бизнес-логики.

1
ответ дан 4 December 2019 в 11:08
поделиться

Из того, что мне сказали более опытные разработчики и аналитики, try / catch более объектно-ориентированный, а если более процедурный.

Мне лично все равно.

Я знаю, что try / catch медленнее и приводит к снижению производительности, но если я собираюсь использовать дюжину if для проверки, прежде чем я смогу сделать то, что хочу, я всегда буду использовать try / catch, чтобы сэкономить на количестве строк кода.

Мне стало намного проще не проверять что-либо, и если оператор не сработает, просто делайте то, что я сделал бы в своем блоке else ... в мой блок 'catch'.

Иногда я, очевидно, заключаю некоторые операторы if в try / catch, но в любом случае.

Я использую if, когда нужно проверить только небольшое количество вещей (1 или 2) перед выполнением что мне нужно сделать.

1
ответ дан 4 December 2019 в 11:08
поделиться

Есть одна вещь, о которой здесь не упоминалось.

При использовании оператора if-else каждый раз, когда выполняется код, по крайней мере одно условие гарантированно оценивается выполненным. Я уверен, что все мы знаем, как работает if-else-elseif, но для ясности ... часть оператора if всегда будет оцениваться, если оно ложно, то следующее else -if и так далее до тех пор, пока не останется только else .

Таким образом, использование оператора if-else повлияет на вашу производительность. Несущественно (в большинстве случаев), но для выполнения оценок требуется процессорное время.

операторы try-catch и исправьте меня, если я ошибаюсь, не учитывайтесь во время выполнения, пока они не потребуются (т.е. выбрасывается исключение). Так что простое включение вашего кода в try-catch не повлияет на производительность до тех пор, пока исключение не будет перехвачено им.

Кроме того, снижение производительности вызывает не уловка, а выброс.

И еще одно важное замечание: операторы try-catch НИКОГДА не должны использоваться для условной логики. Их следует использовать только для того, для чего они предназначены: обработки исключений!

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

Обычно хорошая идея иметь обработчик исключений на самом верху уровень вашего приложения, чтобы перехватить исключения до того, как их увидит пользователь. В ASP.NET это можно сделать в событии Application_Error файла global.asax. В других языках / средах вы должны сделать это в своем основном цикле, чем бы он ни был.

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

0
ответ дан 4 December 2019 в 11:08
поделиться

@PersonalPerson - Извините, но это просто ленивое кодирование. Вместо того, чтобы использовать try-catch из-за слишком большого количества операторов if, почему бы не провести рефакторинг вашего кода (т.е. поместить логику проверки в отдельный метод). Это сделает ваш код более чистым и читаемым, а также поддержит лучшие практики для повышения производительности.

Никогда не пытайтесь писать код, чтобы получить как минимум # строк. Это всегда плохо кончится. Конечно, вы можете найти более элегантный способ написать что-то, что ваши товарищи-программисты будут охать и ахать, но он просто делает вещи менее читаемыми.

Клянусь, я уже работал с вашим кодом раньше, и это заставило меня задуматься. больно.

0
ответ дан 4 December 2019 в 11:08
поделиться
Другие вопросы по тегам:

Похожие вопросы: