On 8/4/06, Ross Gardler <[EMAIL PROTECTED]> wrote:
Thorsten Scherler wrote:
> El vie, 04-08-2006 a las 09:44 +0000, [EMAIL PROTECTED] escribió:
...
> I will change this, if nobody objects. This includes removing all try
> catches surrounding the calling code.
I like to have lots of log messages. Your approach does not change the
amount of code in use because you if becomes and if...else
Furthermore, testing that the source exists is less efficient than
dealing with the exception when it does not exist (at least in this case).
However, I'm not -1 on you changing it, only -0 - go for it if you have
the desire and nobody objects.
+1 for positive .exists() testing.
> Further I would like to add this to the coding guidelines, that
> exception should be prevented and not using them for debugging.
I'm -1 on defining either as the *only* way to do it. In my opinion both
are acceptable in different circumstances.
I agree with Thorsten, we should document this as our exception
handling strategy. I think the lazy exception catching approach is
very rarely acceptable vs positively testing for a condition that is
perfectly acceptable and expected. If we're saying that the file is
optional, then we should add that logic to the code not just wrap it
with exceptions. I agree with Thorsten to add it to the guidelines,
perhaps you'll change your mind after reading?
http://www.javaworld.com/jw-08-2000/jw-0818-exceptions.html
Performance... Not compelling on a method that gets executed twice in
a apps lifetime. (Twice? Yeah, I'm not sure why it gets executed the
second time)
Verbocity... Not compelling. The added conditionals could still be
factored out if desired, but good design trumps verbocity anyway IMO.
--tim
