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
