I've recently integrated checkstyle (http://checkstyle.sourceforge.net/) into my build. It reports on a defined (with XML) coding convention. Thinking it would be good to follow the official Sun Java Coding Convention, my build is now configured with the included Sun convention adherence report.
One of the deviations from convention it reports is with all of my exception constructors is "Parameter x should be final."
So this leads me to the question, why 'should' one declare passed exception parameters as final? I've never seen this before. I can sorta see the logic but am wondering if this is overkill or if maybe there is some other deep thought I am missing.
Thanks for your input.
Stu [ August 29, 2006: Message edited by: Stu Thompson ]
"This is not to say that design is unnecessary. But after a certain point, design is just speculation." --Philip Chu
You can treat a parameter like a local variable, modify it and play with it all you want. This is considered A Bad Thing, though I would not consider it a hanging offense. Your syntax checker is warning you that it would be better to use a local variable for any modification, and using final will force you to do that.
Here's something I might have done in a weak, lazy moment when somebody sent me a badly formed path:
That would be better as
I'm pretty sure I know of at least one rancher who always uses final on parameters, but not very many. As good and proper as it is, it doesn't add to readability and the worst thing that can possibly happen when we leave it out is not all that bad.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
subject: why 'should' one declare passed exception constructor parameters as final?