Hi,
Excellent idea.
I would propose for an additional extension here: Automatic generation
of a JIRA issue for us to be able to quickly provide fixes in a
proactive way before users actually report the problem.
Regards
Felix
On 01.04.2010 09:23, Carsten Ziegeler wrote:
> Bertrand Delacretaz wrote
>> Hi,
>>
>> I've been thinking about the information conveyed by exceptions, and I
>> think we could do much better with naming them.
>>
>> Using the unchecked SlingException as a base is certainly a good idea,
>> but stack traces often get lost, and end users often have a hard time
>> reporting exactly what happened when they get an exception.
>>
>> To fix this, I suggest using a class naming pattern like:
>>
>> package foo.bar;
>>
>> class Wiz {
>> static class
>> PackageFooBarClassWizMethodGetSomethingProblemComputeException
>> extends SlingException {
>> ...
>> }
>>
>> void getSomething() {
>> if(...something bad happened...) {
>> throw new
>> PackageFooBarClassWizMethodGetSomethingProblemComputeException (...);
>> }
>> }
>>
>> Using a strong naming convention like this for exceptions would make
>> it much easier to find out where a problem happened, without having to
>> hunt for stack traces. Any Sling user can then report precisely where
>> a problem happened.
>>
>> In the above example, the
>> PackageFooBarClassWizMethodGetSomethingProblemComputeException name
>> makes it very clear that there was a problem in the getSomething
>> method of the Wiz class in package foo.bar, and the problem is a
>> ComputeException. Bit of a longish name, but we all have cool IDEs,
>> right?
>>
>> Exceptions classes like
>> PackageFooBarClassWizMethodGetSomethingProblemComputeException should
>> probably be generated, as it's somewhat boring code to type. We can
>> think about creating a few annotations, a java code preprocessor or
>> bytecode generator, a maven plugin and some javadoc extensions if we
>> agree on the basic idea. Maybe we should organize a hackathon soon to
>> design this, as it's a big change in the exceptions paradigm. And
>> maybe create a new JSR, as we want Sling to be based on standards.
>> Again, if we agree on the basics. Thinking about it...maybe JVMs could
>> generate those class names based on where the Exception is thrown.
>> Hmm....
>>
>> I don't think I've seen this used in any java software yet, so it
>> might look unusual but being different is a great way of making Sling
>> more visible. I'm going to reserve the spp.org domain ASAP as we might
>> need a place to describe this new revolutionary technique. Tell them
>> you saw it here first!
>>
> Great idea, +1 - now, actually I started to use this two years ago in my
> Catapult prototype....but never finished this....
>
> But I think we can go one bit further: the location alone is only one
> part of the story. The other part is the current "input" which means
> parameters passed into the method, local variables, instance variables
> etc. I think we should add some more bytecode stuff which adds all the
> contents of these variables to the exception.
>
> This would make debugging even easier as you don't actually need to
> debug anymore - and who likes debugging anyway? As soon as an exception
> is thrown you get the full range of information in your face and can
> immediately see what's wrong.
>
> Really like that!
>
> Carsten
