Аспектно-ориентированное программирование: различия между версиями
Содержимое удалено Содержимое добавлено
Строка 206:
Есть множество обрабатываемых исключений в языке [[w:Java]]. Зачастую создаются такие методы, которые наверняка не должны вызывать исключений, и, возможно, они не будут происходить ни у кого из потенциальных пользователей метода. Мы не призываем игнорировать возможные исключения, но тяжело отслеживать присутствие исключений во всех вызовах метода. Есть разные искусные способы использования блоков try/catch, чтобы все-таки решить эту задачу, но самый элегантный — это declare soft в AspectJ. Рассмотрим пример работы с базой данных:
<source lang="java">
{
private Connection conn;
private Statement stmt;
{
conn = DriverManager.getConnection("url for testing purposes");
stmt = conn.createStatement();
stmt.execute("UPDATE ACCOUNTS SET BALANCE = 0");
}
{
new SqlAccess().doUpdate();
}
}</
Если не использовать AspectJ или объявлять исключение в каждой сигнатуре метода, то пришлось бы встраивать блоки try/catch для обработки SQLException, генерируемого почти каждым методом [[w:Java Database Connectivity|JDBC]] [[w:Интерфейс программирования приложений|API]]. Язык [[w:AspectJ|AspectJ]] позволяет использовать следующий внутренний аспект, чтобы автоматически транслировать все SQLException в org.aspectj.lang.SoftException.
<source lang="java">
{
declare soft : SQLException : within(SqlAccess);
pointcut methodCall(SqlAccess accessor) : this(accessor)
{
System.out.println("Closing connections.");
{
accessor.stmt.close();
}
{
accessor.conn.close();
}
}</
''Pointcut'' и ''advice'' закрывают соединение и оператор после каждого метода из класса SQLAccess, в любом случае, приводит ли он к исключению или завершается нормально. Возможно, это расточительно — использовать обрабатывающий ошибки аспект для одного метода, но если есть намерения добавить некоторые другие методы, использующие соединение и оператор, то такая методика обработки ошибок применялась бы и к ним. Такое автоматическое применение аспектов к новому коду является одним из ключевых проявлений устойчивости AOP: авторам нового кода не нужно знать о взаимно пересекающемся поведении для того, чтобы принимать в нем участие.
| |||