You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2010/04/01 09:12:47 UTC

[RT] Using strong patterned prefixes (SPP) for exception class names

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!

WDYT?
-Bertrand

Re: [RT] Using strong patterned prefixes (SPP) for exception class names

Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Vidar,

On Thu, Apr 1, 2010 at 4:46 PM, Vidar Ramdal <vi...@idium.no> wrote:
> ...This sounded so great to me, and knowing how much Bertrand appreciates
> automated tests, I went ahead and implemented tests for all exceptions
> we will possibly need....

Fantastic! We might need more Hudson instances to run all those tests,
but it seems like the ASF just got some fresh money [1] so I'll
probably buy a used cluster or two from Google, and we can then use
that.

>
> Take a look (esp you, Bertrand), and tell me what you think:
> http://tinyurl.com/2g9mqh
>

Thanks! I did take a look, with curl, and that absolutely meets my
expectations ;-)

-Bertrand

[1] https://blogs.apache.org/foundation/entry/the_apache_software_foundation_receives

Re: [RT] Using strong patterned prefixes (SPP) for exception class names

Posted by Vidar Ramdal <vi...@idium.no>.
On Thu, Apr 1, 2010 at 9:12 AM, Bertrand Delacretaz
<bd...@apache.org> 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!
>
> WDYT?

This sounded so great to me, and knowing how much Bertrand appreciates
automated tests, I went ahead and implemented tests for all exceptions
we will possibly need.

Take a look (esp you, Bertrand), and tell me what you think:
http://tinyurl.com/2g9mqh

-- 
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: [RT] Using strong patterned prefixes (SPP) for exception class names

Posted by Felix Meschberger <fm...@gmail.com>.
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

Re: [RT] Using strong patterned prefixes (SPP) for exception class names

Posted by Michael Dürig <mi...@day.com>.
> Wow...now this adds another dimension, excellent!
>
> The exception names might get a bit long then...maybe the exception
> name should be just an md5 of the aggregated info (package, class
> name, method, input variables, VM stack, moon phase etc.) with a
> utility that would rebuild the full exception class name with a double
> reverse hashed lookup.

I mentioned the md5 approach a while back on the Jackrabbit list [1]: an 
advantage of md5 is that it would automatically serve as hash tag for 
search engines: searching for an md5 would lead to forum 
posts/FAQs/mailing lists/manuals where the issue is discussed. Searching 
for md5s would result in much fewer false positives than searching i.e. 
for "SlingException". To see what I mean Google for "error 0x800cccdd" 
and for "error 1" and compare the results.

Of course some care would have to be taken to include the correct 
information in the md5 in order not to be overly specific or general.

Michael

[1] http://markmail.org/message/zthaqbeciu7lom6z

Re: [RT] Using strong patterned prefixes (SPP) for exception class names

Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Apr 1, 2010 at 9:23 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Bertrand Delacretaz wrote
>> ...  void getSomething() {
>>     if(...something bad happened...) {
>>       throw new
>> PackageFooBarClassWizMethodGetSomethingProblemComputeException (...);...

> ...Great idea, +1 - now, actually I started to use this two years ago in my
> Catapult prototype....but never finished this....

Ah yes, Catapult...I should have a look, there were great ideas in there!

>
> ...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....

Wow...now this adds another dimension, excellent!

The exception names might get a bit long then...maybe the exception
name should be just an md5 of the aggregated info (package, class
name, method, input variables, VM stack, moon phase etc.) with a
utility that would rebuild the full exception class name with a double
reverse hashed lookup.

> ...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....

Right, this could speed up development in a dramatic way.

Anyone got contacts at the JCP?
This definitely sounds like a new standard in the making.

Food for thought....
-Bertrand

Re: [RT] Using strong patterned prefixes (SPP) for exception class names

Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org

Re: [RT] Using strong patterned prefixes (SPP) for exception class names

Posted by Carsten Ziegeler <cz...@apache.org>.
Alexander Klimetschek  wrote
> On Thu, Apr 1, 2010 at 09:12, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>> 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?
> 
> +1, but I think this isn't enough information. We should include the
> author and revision number as well, so that people can easily find out
> which version of the code to look at and who to blame on the mailing
> list.
> 
> Anything else? Maybe other interesting metadata such as the editor/IDE
> in which the code was written, a short twitter-like status, etc. So we
> get something like this:
> 
> PackageFooBarClassWizMethodGetSomethingProblemComputeExceptionRevision201041WrittenByBertrandInEclipse35NiceWheatherToday
Ah yes, and mentioning twitter, what about tweeting the exception to the
project tweet? So the developers immediately see when their code is
throwing an exception and they maybe can fix/change their code even
before the user is able to summit a report to the issue tracker.

> 
> I think the JCP discussion are going to be very interesting!
> 
Definitly! And its worth the effort!

Carsten

> Regards,
> Alex
> 


-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [RT] Using strong patterned prefixes (SPP) for exception class names

Posted by Carsten Ziegeler <cz...@apache.org>.
Brett Porter  wrote
> 
> On 01/04/2010, at 7:00 PM, Alexander Klimetschek wrote:
> 
>> On Thu, Apr 1, 2010 at 09:12, Bertrand Delacretaz
>> <bd...@apache.org> wrote:
>>> 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?
>>
>> +1, but I think this isn't enough information. We should include the
>> author and revision number as well, so that people can easily find out
>> which version of the code to look at and who to blame on the mailing
>> list.
>>
>> Anything else? Maybe other interesting metadata such as the editor/IDE
>> in which the code was written, a short twitter-like status, etc. So we
>> get something like this:
>>
>> PackageFooBarClassWizMethodGetSomethingProblemComputeExceptionRevision201041WrittenByBertrandInEclipse35NiceWheatherToday
> 
> The only problem I can see here is that you are approaching the 140-character limit, and given all future communication is likely to take place on Twitter it will be difficult to tell your fellow developer what went wrong at all. Perhaps it needs a built-in shortening service that IDEs will soon adopt and generate for you?
> 
> The above would generate some code like "dcXTUr" or "FaiLlolz", so the exception is reduced to "on.excepti.FaiLlolz"
> 
> Then you can easily tweet it: "@bdelacretaz argh, you broke FooBarClass again! http://excepti.on/FaiLlolz #spp"
> 
Awesome, I think to simplify the first implementation we can hard code
some information like the author to the values from above...

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [RT] Using strong patterned prefixes (SPP) for exception class names

Posted by Brett Porter <br...@apache.org>.
On 01/04/2010, at 7:00 PM, Alexander Klimetschek wrote:

> On Thu, Apr 1, 2010 at 09:12, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>> 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?
> 
> +1, but I think this isn't enough information. We should include the
> author and revision number as well, so that people can easily find out
> which version of the code to look at and who to blame on the mailing
> list.
> 
> Anything else? Maybe other interesting metadata such as the editor/IDE
> in which the code was written, a short twitter-like status, etc. So we
> get something like this:
> 
> PackageFooBarClassWizMethodGetSomethingProblemComputeExceptionRevision201041WrittenByBertrandInEclipse35NiceWheatherToday

The only problem I can see here is that you are approaching the 140-character limit, and given all future communication is likely to take place on Twitter it will be difficult to tell your fellow developer what went wrong at all. Perhaps it needs a built-in shortening service that IDEs will soon adopt and generate for you?

The above would generate some code like "dcXTUr" or "FaiLlolz", so the exception is reduced to "on.excepti.FaiLlolz"

Then you can easily tweet it: "@bdelacretaz argh, you broke FooBarClass again! http://excepti.on/FaiLlolz #spp"

WDYT?

Cheers,
Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/





Re: [RT] Using strong patterned prefixes (SPP) for exception class names

Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Apr 1, 2010 at 09:12, Bertrand Delacretaz
<bd...@apache.org> wrote:
> 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?

+1, but I think this isn't enough information. We should include the
author and revision number as well, so that people can easily find out
which version of the code to look at and who to blame on the mailing
list.

Anything else? Maybe other interesting metadata such as the editor/IDE
in which the code was written, a short twitter-like status, etc. So we
get something like this:

PackageFooBarClassWizMethodGetSomethingProblemComputeExceptionRevision201041WrittenByBertrandInEclipse35NiceWheatherToday

I think the JCP discussion are going to be very interesting!

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com