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.
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.
Context info and stack trace have helped me many times!
Greetings,
Marko Klopcic
On 07/07/2011 12:53 PM, Stephen Colebourne wrote:
On 7 July 2011 11:48, Jörg Schaible<joerg.schai...@scalaris.com> wrote:
One last opinion about the output? Originally we had e.g.:
[Handler = PersonConverter]
[Current Element = Person]
[Role = COO]
[Handler[1] = CompanyConverter]
[Current Element[1] = Company]
The current output does no longer have the "[1]" numbering at the keys.
However, I wonder if the plain output sequence is now enough for easy
analysis, whether I should add those indexes again (for the formatted
message only) or should add an additional element numbering e.g. like:
[1:Handler = PersonConverter]
[2:Current Element = Person]
[3:Role = COO]
[4:Handler = CompanyConverter]
[5:Current Element = Company]
The default message should probably have numbering as per [1:Handler
= PersonConverter]
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
