2012-03-07 1 views
4

Интересно, всегда ли мне приходится использовать блоки try-catch-error, которые сильно загромождают код, если я хочу поймать ошибку.Всегда пытайтесь поймать - наконец, за исключения? Центральное управление ошибками?

Или я могу как-то определить глобальную ошибку? Особенно в отношении Java EE Webapps.

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

Я думал, что могу достичь этого с помощью аспектов. Но для аспектов, которые нужно поймать на @AfterThrowing, мне тоже нужно представить блоки try-catch. И поскольку для фасадов-фасадов нет центрального класса, мне пришлось бы окружить каждый метод поддержки с помощью trycatches. Тогда аспект возьмет их, но мне нужно что-то поймать без явных исключений бросков.

Как я мог это сделать?

ответ

3

Вы ищете конструкцию declare soft. Это обернет данное исключение в SoftException (исключение RuntimeException, специфичное для AspectJ), так что его не нужно явно обрабатывать. Затем вы можете обрабатывать все эти исключения с помощью совета AfterThrowing.

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

Смотрите здесь: http://www.eclipse.org/aspectj/doc/released/progguide/quick-other.html

И здесь: http://www.eclipse.org/aspectj/doc/released/adk15notebook/declare-soft.html


EDIT

Вот фрагмент кода, который показывает, как это можно сделать:

aspect ErrorHandler { 
    declare soft : Exception : within(*); 
    after() throwing(Exception e) : handler(e) { 

    // do something... 
    } 
} 

Это Wi ll route все исключений в вашей системе через ваш пользовательский обработчик ошибок. И вам не нужно явно их поймать или выбросить.

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

0

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

В какой степени? Я бы связал это со сложностью/ожидаемым сроком службы вашего приложения. Чем больше это, тем лучше должно быть ваше обращение.

Я вижу два основных approachs: подход

  • пользователя: Вы получаете обработку по крайней мере одно исключения для каждого действия пользовательского интерфейса (так что вы можете сказать: «Не нажимайте на эту кнопку СНОВА»).

  • Подход отладчика: каждый метод имеет свой контроль.

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

К тому же, скорее всего, ваша инфраструктура Java EE будет иметь параметры журнала в своих конфигурационных файлах (многие из них работают с java.util.loggin или log4j). Вы могли бы настроить это; конечно, то, что отправляется в каждую категорию журнала, будет зависеть от реализации структуры (поэтому, возможно, не все сообщения ERROR будут Исключениями).

1

Вам не нужно делать это в каждом методе.

Вы не должны ловить исключение, которое вы не можете «обрабатывать». Обработка означает больше, чем просто реорганизация или ведение журнала или печать трассировки стека. Я считаю, что обработка означает реализацию значимой стратегии восстановления.

Это может означать, что «доллар останавливается здесь»: вы Гэндальф на мосту у края границы слоя, и никакое исключение не пройдет. Вы не хотите, чтобы пользователи видели неприятные сообщения, поэтому вы ловите их и отправляете их другу, легко понимаете страницу, которая сообщает им, что делать дальше.

Наконец, это не всегда необходимо, но оно идеально подходит для очистки ресурсов, таких как ручки файлов и курсоры баз данных.

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

1

В общем случае нет механизма для этого - у Java нет того, что вы ищете.

Однако, в зависимости от обстоятельств, возможно.

web.xml Exception Handler

web.xml Файл позволяет определить URL, которые будут использоваться для обработки указанного типа исключения. (См., Например, http://wiki.metawerx.net/wiki/Web.xml.ExceptionType).
Поскольку вы пишете webapp, вы можете просто позволить исключениям отбросить весь путь до вершины, а затем обработать их таким образом.

Пользовательского перехватчик

Вы сказали, что у вас есть бэк-фасады. В зависимости от того, как они создаются, вы можете поставить общий прокси-сервер перед ними, чтобы поймать и обработать те исключения, которые вас интересуют. Вы отметили свой вопрос spring, вам может потребоваться посмотреть Прокси-серверы Spring AOP.

Могут быть другие способы получить то, что вы хотите, но это будет зависеть от особенностей архитектуры вашего приложения.

+0

Вопрос не в Java, а о AspectJ. –

+0

@AndrewEisenberg - Это о веб-приложениях JEE, и в нем помечены 'java',' spring' и 'aspectj'. Нет причин не предлагать решение, которое является чистой Java. – Tim

+0

Достаточно. Я был отброшен вашей первой строкой «нет механизма для этого». В чистом JEE нет, но решение в AspectJ тривиально. –