Добивайтесь атомарности методов по отношению к сбоям

 

После того как объект инициирует исключение, обычно необходимо, Ч1'обы он оставался во вполне определенном, пригодном для дальнейшей обработки состоянии, даже несмотря на то, что сбой произошел непосредственно в процессе ВЫl1Dлнения -операции. Особенно это касается обрабатываемых исключений, когда предполагается, что клиент будет восстанавливать работоспособность программы. Вообще говоря, вызов метода, завершившийся сбоем, должен оставлять обрабатываемый объект в том же состоянии, в каком тот был перед вызовом. Метод, обладающий таким свойством, называют атомарным по отношению к сбою (failure atomic).

Добиться такого эффекта можно несколькими способами'. Простейший способ заключается в создании неизменяемых объектов (статья 13). Если объект неизме­няемый, получение атомарности не требует усилий. Если операция заканчивается сбоем, это может помешать созданию нового объекта, но никогда не оставит уже имеющийся объект в неопределенном состоянии, поскольку состояние каждого неиз­меняемого объекта согласуется в момент его создания и после этого уже не меняется.

для методов, работающих с изменяемыми объектами, атомарность по отношению к сбою чаще всего достигается путем проверки правильности параметров перед выполнением операции (статья 23). Благодаря этому, любое исключение будет иниции­роваться до того, как начнется модификация объекта. В качестве примера рассмотрим метод Staok.рор из статьи 5:

 

public Objeot рор() {

if (size == 0)

throw new EmptyStaokExoeption();

 

 

 

173

 

Object result = elements[-size];

       elements[size] = null; // Убираем устаревшую ссылку

return result;

 

Если убрать начальную проверку размера, метод все равно будет инициировать исключение при попытке получить элемент из пустого стека. Однако при этом он бу­дет оставлять поле size в неопределенном (отрицательном) состоянии. А это приведет к тому, что сбоем будет завершаться вызов любого метода в этом объекте. Кроме того, само исключение, инициируемое методом рор, не будет соответствовать текущему уровню абстракции (статья 43).

Другой прием, который тесно связан с предыдущим и позволяет добиться атомар­ности по отношению к сбоям, заключается в упорядочении вычислений таким образом, чтобы все фрагменты кода, способные повлечь сбой, предшествовали первому фраг­менту, который модифицирует объект. Такой прием является естественным расши­рением предыдущего в случаях, когда невозможно произвести проверку аргументов, не выполнив хотя бы части вычислений. Например, рассмотрим случай с классом ТгееМар, элементы которого сортируются по не коему правилу. Для того чтобы в экземпляр ТгееМар можно было добавить элемент, последний должен иметь такой тип, который допускал бы сравнение с помощью процедур, обеспечивающих упорядочение ТгееМар. Попытка добавить элемент неправильного типа, естественно, закончится сбоем (и исключением ClassCastException), который произойдет в процессе поиска этого элемента в дереве, но до того, как в этом дереве что-либо будет изменено.

Третий, редко встречающийся прием, заключается в написании специального кода восстановления (recovery code), который перехватывает сбой, возникающий в ходе выполнения операции, и заставляет объект вернуться в то состояние, в котором он находился в момент, предшествующей началу операции. Этот прием используется главным образом для структур, записываемых в базу данных.

Наконец, последний прием, позволяющий добиться атомарности метода, заклю­чается в том, чтобы выполнять операцию на временной копии объекта, и как только операция будет завершена, замещать содержимое объекта содержимым его временной копии. Такой прием подходит для случая, когда вычисления могут быть выполнены намного быстрее, если поместить данные во временную структуру. Например, метод Collections.sort перед выполнением сортировки загружает полученный список в некий массив с тем, чтобы облегчить доступ к элементам во время внутреннего цикла сортировки. Это сделано для повышения производительности, однако имеет и другое дополнительное преимущество - гарантию того, что предоставленный мето­ду список останется нетронутым, если процедура сортировки завершится сбоем.

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

Например, если два потока одновременно, без должной синхронизации пытаются модифицировать некий объект, последний может остаться в неопределенном состоя­нии. А потому после перехвата исключения ConcurrentModificationException нельзя

 

 

 

 

 

 

 

 

 

174

 

 

полагаться на то, что объект все еще при годен к использованию. Ошибки (в отличие от исключений), как правило, невосстановимы, и потому методам не нужно даже пы­таться сохранять атомарность в случае появления ошибки.

Даже там, где можно получить атомарность по отношению к сбоям, она не всегда желательна. Для некоторых операций она существенно увеличивает затраты ресурсов и Сложность вычислений. Вместе с тем очень часто это свойство достигается без особого Труда, если хорошо разобраться с проблемой. Как правило, любое исключе­ние, добавленное в спецификацию метода, должно оставлять объект в том состоянии, в котором он находился до вызова метода. В случае нарушения этого правила в доку­ментации API Должно быть четко указано, в каком состоянии будет оставлен объект. К сожалению, множество имеющейся документации к API не стремится достичь этого идеала.

 

⇐ Предыдущая33343536373839404142Следующая ⇒

Поделиться: