pig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "pi song" <pi.so...@gmail.com>
Subject Re: Proposal for error handling in Pig
Date Tue, 04 Mar 2008 03:49:28 GMT
I found an article in wikipedia regarding assertion which is really worth
reading!!
http://en.wikipedia.org/wiki/Assertion_%28computing%29

And I would like to emphasize the distinction between assertions and error
handling. Please read under the header "Comparison with error handling"

Cheers,
Pi

On 3/4/08, pi song <pi.songs@gmail.com> wrote:
>
> Olga,
>
> You're right. You need a special flag to enable assertion checking in
> Sun's JVM. One scenario in using assertions that I find appropriate is to
> enforce design-by-contract between developers (pre-condition checking). Then
> these checks sometimes are expensive so when in production if we don't
> enable assertions we can save some CPU cycles(Though I can't confirm that
> Sun JIT compiler strips assertions out while compiling the VM code).
>
> I want to make it clear here (though it already seems to be obvious) that
> assertion isn't for mechanism for handling errors in applications. It's only
> just a tool for helping developers in development time. (However this
> doesn't deprive you an option for users to run in assertion-enabled mode
> when tracking down problems)
>
> By the way, I totally agree that exceptions should be handled at higher
> level. The classification of exceptions in Wiki sounds good to me (except
> the assertion bit)
>
> One question from me is "Do we treat UDF exception as user exception?"
>
> Cheers,
>
> Pi
>
>
> On 3/4/08, Olga Natkovich <olgan@yahoo-inc.com> wrote:
> >
> > Hi Stefan,
> >
> > Thanks for your comments. My responses inline.
> >
> > > User Errors:
> > > Agreed meaningful error messages for the user.
> > > + should we start using error codes and a message bundle for i18n in
> > > the very long run?
> >
> > Sounds good.
> >
> > > + in debug mode we should also show the complete strack trace
> >
> > That's fine, I updated the document.
> >
> > > Internal Errors:
> > > + java has assert statements and I like them very much since it helps
> > > to better understand the code - best documentation is always
> > > the code, isnt it? :)
> > > http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
> > > It would be great to make the usage of assert to a coding
> > > standard in pig
> >
> > I have never used asserts is Java. What do people that used them think?
> > One thing that seems bad is that, according to the document, asserts are
> > disabled at runtime by default. I think we want to always have them on
> > or at least on by default. If users use the frontend script to run Pig,
> > that's not a problem. However, we don't want to make that a requirement.
> >
> > > "log the exception message to stderr": I suggest that we do
> > > always log using commons logging and have a Console appender
> > > and not logging into stderr directly.
> >
> > Yes. I meant what would happen - not how we would do it :).
> >
> > > Can we find a better name than Frontend Exception? Frontend
> > > is widely used for User Interface as well. Maybe Client - but
> > > I'm not very happy about client also. :-/
> >
> > I don't want to have a big discussion on names :). The same name can be
> > very intuitive to some and completely foreign to others. We would just
> > have to live with that :).
> >
> > > In general I'm in favor of the idea of having those
> > > exceptions. All pig exceptions should inheritance from
> > > RuntimeException. This would allow us to design API without
> > > Exception declaration (unchecked Exceptions). Since your
> > > proposal suggest to handle the error always on very top in
> > > the stack (what I like a lot) this will clean up all API and
> > > make them better understandable.
> > > http://www.javapractices.com/topic/TopicAction.do?Id=129
> > > http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html
> >
> > Yes, I like the idea of all exceptions to be subclasses of
> > RuntimeException. Those warnings are quite annoying. However,
> > ParseException is not derived from RuntimeException so we would need to
> > make exception for it :).
> >
> > > I'm always happy to assit in doing your suggest changes since
> > > we have a hight need in getting pig into a production ready
> > > state soon than later. :) Just let me know.
> >
> > Thanks. Lets sort out the plan and then maybe you can add the missing
> > pieces.
> >
> > Olga
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message