Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> using production asserts

Copy link to this message
Re: using production asserts
Thanks! When I have time I'll take a look into those. From cursory check,
guava uses exceptions so it wouldn't be the same thing given the tendency
to catch all...

On Thu, Dec 6, 2012 at 10:31 AM, Stack <[EMAIL PROTECTED]> wrote:

> On Thu, Dec 6, 2012 at 10:26 AM, Sergey Shelukhin <[EMAIL PROTECTED]
> >wrote:
> > Hi.
> > In the previous projects, I got used to using production (cheap) asserts
> > all over the code to verify strictly internal state (e.g., random
> example,
> > we take a buffer out of "buffers to flush" pool and it still has writers
> > attached - how did it end up in this pool? we don't know what's going on
> > anymore).
> > If such thing happens the process would force crash (no exception
> handling
> > will save it), writing a dump and debug info according to configuration.
> > That serves well to detect bugs early, and to be more confident about
> what
> > the code is doing (and not write code that tries to account for unknwon
> > bugs in other code) :)
> > Although it does increase the number of crashes potentially, if enabled;
> > and can be misuses if someone uses it for external conditions.
> >
> > I notice there's no such practice in HBase codebase... was it rejected at
> > some point, or just never used?
> > I wonder if it would be a good idea for me to look at some Java options
> for
> > that, and introduce it for people who might want to give it a try.
> >
> There are java asserts:
> http://docs.oracle.com/javase/1.4.2/docs/guide/lang/assert.html
> They are used sporadically in test code mostly and in the odd place in
> mainline code.
> The flag to enable asserts is on when unit tests run (IIRC).
> There is also guava's precondition checking that fellas are starting to
> use: http://code.google.com/p/guava-libraries/wiki/PreconditionsExplained
> There is no rule against profligate use of either to my knowledge Sergey.
> St.Ack