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
--
Carsten Ziegeler
[email protected]
