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 <[EMAIL PROTECTED]> 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 >
