Hi Marko, Marko Klopcic wrote:
> Hi, > > It is probably a bit late, but it is only these days I've checked > javadoc of the commons-lang ver. 3 on the web, and found contexted > exceptions. I found the context info useful already some time ago, so > I've implemented my own classes, which you can find at > > http://www.trimah.com/eng/index.php/tools-for-developers/2-java-exceptions > > I'm ready to share my experience and also to help with implementation. > It is also no problem to change the license of my code to Apache License. > > I'd suggest to add interface for Exception formatter, and one or two > implementations (I have only impl. KEFormatter). If formatter > is separate from exception implementation, it is easier to use it > also with standard Java exceptions. I also find > YAML format very readable and parsers for it already exist. The current implementation of DefaultExceptionContext will simply generate a readable string used e.g. as exception message. It's no problem to use a different implementation or create one that is based on a formatter. Additionally a formatter may simply use an object implementing ExceptionContext to create something else. I don't see that generating JAML, XML or JSON is within the focus of lang itself and due to the architecture I also don't see any requirement to provide a formatter interface from lang itself (as explained, it is independent anyway). > I also have one question - is it OK to add a GUI class to the > lang library? I have implementation of an exception dialog, which > has two panes - upper one for text messages and context info, bottom > one for stack info, when the user presses 'Details button'. I also > plan to add 'Copy' button so users can easily copy-paste error info > to mail when asking for help. Again, complete user dialogs are also out of scope. I can imagine that a small package that combines the formatters and such a dialog based on the ExceptionContext stuff makes a valuable addition on its own. > Context info and stack trace have helped me many times! Definitely. Cheers, Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
