There is no reason per se other than the limited use cases of the initial implementation and the principle of doing as little as necessary to meet them while (hopefully) not limiting extension to handle additional use cases over time.
Those use cases fall into two categories IMHO: - Authoritative decisions in the preXXX hooks. - Adding to or transforming API usage, in a stateless manner. Adding .failedXXX methods in the way you propose seems reasonable. I filed HBASE-5827 for further discussion, please see https://issues.apache.org/jira/browse/HBASE-5827 Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White) ----- Original Message ----- > From: Benjamin Busjaeger <busjae...@googlemail.com> > To: dev@hbase.apache.org > Cc: > Sent: Thursday, April 19, 2012 4:18 AM > Subject: RegionObservers notifications on error > > Is there a reason that RegionObservers are not notified when a get/put/delete > fails? Suppose I maintain some (transient) state in my Coprocessor that is > created during preGet and discarded during postGet. If the get fails, postGet > is > not invoked, so I cannot remove the state. > > If there is a good reason, is there any other way to achieve the same thing? > If > not, would it be possible to add something the snippet below to the code > base? > > > <https://github.com/apache/hbase/blob/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java#L4073> > > https://github.com/apache/hbase/blob/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java#L4067 > // pre-get CP hook > if (withCoprocessor && (coprocessorHost != null)) { > if (coprocessorHost.preGet(get, results)) { > return results; > } > } > + try{ > ... > + } catch (Throwable t) { > + // failed-get CP hook > + if (withCoprocessor && (coprocessorHost != null)) { > + coprocessorHost.failedGet(get, results); > + } > + rethrow t; > + } > > // post-get CP hook > if (withCoprocessor && (coprocessorHost != null)) { > coprocessorHost.postGet(get, results); > } > > > Thanks, > Ben >
