Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #24417 > unrolled thread

About java program.

Back to article view | Back to comp.lang.java.programmer

Contents

  About java program. rajbhaumik@gmail.com - 2013-06-15 13:38 -0700
    Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-06-15 16:50 -0400
    Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-06-16 01:12 +0200
      Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-16 14:21 +0100
        Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-06-16 17:28 +0200
          Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-16 19:52 +0100
            Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-06-16 15:50 -0400
          Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-17 09:36 +0100
          Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-17 09:49 -0300
            Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-17 14:46 +0100
              Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-17 13:32 -0300
              Re: About java program. Joerg Meier <joergmmeier@arcor.de> - 2013-06-17 20:32 +0200
                Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-06-17 14:49 -0400
                  Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-17 18:38 -0300
                    Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-06-17 18:30 -0400
                      Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-18 17:33 -0300
                    Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 22:56 -0400
                  Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-18 00:13 +0200
                    Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-18 17:50 -0300
                      Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-19 08:50 +0100
                        Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-19 15:16 -0300
                          Re: About java program. Lew <lewbloch@gmail.com> - 2013-06-19 16:20 -0700
                            Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 13:31 -0400
                              Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 18:16 -0400
                              Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 19:21 -0400
                                Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 20:07 -0400
                                  Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 20:21 -0400
                                    Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 20:40 -0400
                                  Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 22:20 -0400
                                    Re: About java program. Lew <lewbloch@gmail.com> - 2013-07-07 21:47 -0700
                                      Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-08 06:58 -0400
                                        Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-08 08:07 -0400
                                          Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-08 08:58 -0400
                                            Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-08 09:18 -0400
                                              Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-08 09:47 -0400
                                                Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-08 10:07 -0400
                      Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-19 16:42 +0200
                        Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-20 23:33 -0300
                          Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-06-21 04:16 +0000
                            Re: About java program. Joerg Meier <joergmmeier@arcor.de> - 2013-06-21 12:27 +0200
                              Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-06-21 21:14 +0000
                                Re: About java program. Joerg Meier <joergmmeier@arcor.de> - 2013-06-21 23:37 +0200
                                  Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-06-21 23:42 +0000
                                Re: About java program. Gene Wirchenko <genew@telus.net> - 2013-06-24 13:00 -0700
                                  Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-06-24 21:29 +0000
                                    Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-06-24 21:42 +0000
                            Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-21 23:59 -0300
                              Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-06-22 13:30 +0000
                          Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-21 16:24 +0200
                            Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-21 22:39 -0300
                              Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-22 19:25 +0200
                                Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-22 19:41 +0100
                                  Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-23 03:53 +0200
                                    Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-23 09:21 +0100
                                      Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-24 18:57 +0200
                                        Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-24 18:14 +0100
                            Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-22 09:03 +0100
                              Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-22 19:26 +0200
                                Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-22 18:51 +0100
                      Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 22:58 -0400
                  Re: About java program. Joerg Meier <joergmmeier@arcor.de> - 2013-06-19 00:38 +0200
                    Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-06-18 18:56 -0400
                      Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-18 21:26 -0300
                        Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-06-19 21:20 +0200
                          Re: About java program. Sven Köhler <remove-sven.koehler@gmail.com> - 2013-06-20 11:23 +0300
                            Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-06-20 19:18 +0200
                              Re: About java program. blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2013-07-15 20:20 +0000
                      Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-19 09:14 +0100
                    Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-19 09:11 +0100
                      Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 23:11 -0400
                        Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-07-05 09:13 +0100
                          Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-07-05 23:15 +0200
                            Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-05 22:03 -0400
                              Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-07-06 13:01 +0200
                                Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-07-06 13:43 +0100
                                Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-07-06 14:17 +0000
                                Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-06 16:18 -0400
                                  Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-07-06 21:42 +0100
                            Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-07-06 09:16 +0100
                              Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-07-06 13:14 +0200
                                Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-06 08:22 -0400
                                  Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-07-07 20:43 +0200
                                    Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-07 18:07 -0400
                                      Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-07 19:35 -0400
                                        Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-07 20:42 -0400
                                      Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-07-08 20:50 +0200
                                        Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-08 15:01 -0400
                                          Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-07-08 23:29 +0200
                                Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-06 16:27 -0400
                                  Re: About java program. Lew <lewbloch@gmail.com> - 2013-07-06 13:41 -0700
                          Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-05 21:59 -0400
                Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-17 21:06 +0100
              Re: About java program. Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-06-17 17:36 -0500
                Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-06-18 08:24 +0200
                Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-18 09:03 +0100
                  Re: About java program. Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-06-18 13:07 -0500
                  Re: About java program. Lew <lewbloch@gmail.com> - 2013-06-18 14:48 -0700
                    Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-19 08:36 +0100
                Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-18 23:33 -0300
                  Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-19 08:34 +0100
              Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 22:53 -0400
    Re: About java program. Roedy Green <see_website@mindprod.com.invalid> - 2013-06-16 07:04 -0700
    Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-06-18 04:06 -0400

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#24458

On Mon, 17 Jun 2013 14:49:38 -0400, Eric Sosman wrote:

> On 6/17/2013 2:32 PM, Joerg Meier wrote:
>>[...]
>> Personally, I found your example considerably harder to read than the one
>> liner, as well as harder to read than what would have been my solution:
>>
>> private boolean askYesNoquestion (String str){
>>      if(str.equals("yes"))
>>          return true;
>>
>>      return false;
>> }
>      Or, for even greater clarity:

Obviously, in the case of booleans, this style is superfleous (and
especially in something this simple), but I was trying to demonstrate the
style, not write a better askYesNoquestion method.

However, as for returning true/false instead of expressions, while this
would be possible in this extremely simple example, the moment you have
more conditions, you end up either writing something hard to read with lots
of && and ||, or you end up with duplicate expressions, or you can go with
returning true/false.

I don't find "return (((x && y) || a && (z || v)) && c);" to be terribly
readable. "Exploding" that into a more verbose if/else structure often ends
up making code a lot more maintainable than the 'every extra letter must be
conserved' school of thinking.

Frankly, I'm surprised that even though it should be obvious that my code
was no more supposed to be production code for a method that simple,my

"if (x) return true"

faced so much more ridicule than lipskas 

"boolean var; if (x) var = true; return var",

which is basically the same only even more verbose.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#24459

On 6/18/2013 6:38 PM, Joerg Meier wrote:
>[...]
> Frankly, I'm surprised that even though it should be obvious that my code
> was no more supposed to be production code for a method that simple,my
>
> "if (x) return true"
>
> faced so much more ridicule than lipskas
>
> "boolean var; if (x) var = true; return var",
>
> which is basically the same only even more verbose.

     Perhaps you attract more ridicule because your posts have a
wider readership than lipska's.  That explains my reaction, at
any rate.

     `if (bool) return true; else return false;' does have one
small advantage over `return bool;' in that it's easier to
plant a breakpoint on one branch but not on the other, if a
debugging session gets down to "This shouldn't be true, should
it?  *Should* it?"  Similarly, the style of assigning a
`result' variable throughout the body of a method and returning
it only at the end makes it easy to trap and trace "unusual"
values.  In my experience these advantages are occasionally
worth the extra clutter -- but only occasionally.  YMMV.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#24460

On 06/18/2013 07:56 PM, Eric Sosman wrote:
> On 6/18/2013 6:38 PM, Joerg Meier wrote:
>> [...]
>> Frankly, I'm surprised that even though it should be obvious that my code
>> was no more supposed to be production code for a method that simple,my
>>
>> "if (x) return true"
>>
>> faced so much more ridicule than lipskas
>>
>> "boolean var; if (x) var = true; return var",
>>
>> which is basically the same only even more verbose.
>
>      Perhaps you attract more ridicule because your posts have a
> wider readership than lipska's.  That explains my reaction, at
> any rate.
>
>      `if (bool) return true; else return false;' does have one
> small advantage over `return bool;' in that it's easier to
> plant a breakpoint on one branch but not on the other, if a
> debugging session gets down to "This shouldn't be true, should
> it?  *Should* it?"  Similarly, the style of assigning a
> `result' variable throughout the body of a method and returning
> it only at the end makes it easy to trap and trace "unusual"
> values.  In my experience these advantages are occasionally
> worth the extra clutter -- but only occasionally.  YMMV.
>
I find the style of clearly declaring a result variable at the beginning 
of a method often comes about because you have to declare the variable 
anyway, because of try-catch and conditional blocks and so forth. So it 
may as well get declared early.

I don't think it's a style to either decry or enthusiastically endorse. 
It hardly introduces clutter, though.

AHS

-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#24474

On 19.06.2013 02:26, Arved Sandstrom wrote:

> I find the style of clearly declaring a result variable at the beginning
> of a method often comes about because you have to declare the variable
> anyway, because of try-catch and conditional blocks and so forth. So it
> may as well get declared early.

I try to declare in the smallest necessary scope.  And I find myself 
converting

boolean result = false;
try {
   result = whatEver() || somethingElse();
}
catch (whatever...) {
   no return or change of result
}
return result;

to

try {
   return whatEver() || somethingElse();
}
catch (whatever...) {
   no return or change of result
   return false;
}

because I find that more readable.  Variables are not a value in itself. 
  If they don't serve a purpose they should go away IMHO since they 
decouple calculation of the value from usage.  Of course, if you need 
the same value multiple times then that warrants every variable.  But 
cases like the one above do not.

> I don't think it's a style to either decry or enthusiastically endorse.
> It hardly introduces clutter, though.

Right.

Cheers

	robert



-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#24479

Am 19.06.2013 22:20, schrieb Robert Klemme:
> boolean result = false;
> try {
>   result = whatEver() || somethingElse();
> }
> catch (whatever...) {
>   no return or change of result
> }

I would like to add, that I dislike the initialization of result in this
example. If result (for whatever reason) must be declared outside the
try-catch block, then please don't initialize it unless you plan on
doing something nasty. A nasty example would be that the try block sets
result to true midway and an exception in the second half doesn't change
the value of result to false for some weired reason.

The IMHO cleaner way is the following:

boolean result;
try {
  result = whatEver() || somethingElse();
}
catch (whatever...) {
  result = false;
}
// use result for whatever


And may all (ex-)C programmers in this group refrain from telling me
that not initializing variables is dangerous. This is Java, where the
compiler enforces initialization of variables on all code paths before
the first read-access to the variable.


Regards,
  Sven

[toc] | [prev] | [next] | [standalone]

#24487

On 20.06.2013 10:23, Sven Köhler wrote:
> Am 19.06.2013 22:20, schrieb Robert Klemme:
>> boolean result = false;
>> try {
>>    result = whatEver() || somethingElse();
>> }
>> catch (whatever...) {
>>    no return or change of result
>> }
>
> I would like to add, that I dislike the initialization of result in this
> example. If result (for whatever reason) must be declared outside the
> try-catch block, then please don't initialize it unless you plan on
> doing something nasty.

Absolutely.  The reason is that by initializing the variable you forgo 
the Java compiler's data flow analysis.  Without initialization you will 
immediately know if there is a code path which uses the variable without 
prior initialization.

> A nasty example would be that the try block sets
> result to true midway and an exception in the second half doesn't change
> the value of result to false for some weired reason.

Right.

> The IMHO cleaner way is the following:
>
> boolean result;

I'd even recommend making that variable final if possible.

> try {
>    result = whatEver() || somethingElse();
> }
> catch (whatever...) {
>    result = false;
> }
> // use result for whatever

Generally I prefer not to have code after the catch block (unless it's a 
finally block :-)) because that means that error handling is not 
centralized but rather interspersed with other logic.  I have seen 
methods with multiple try catch blocks in them on the same level which 
made them really unreadable.  If that is necessary then I'd either 
combine catch blocks and if that cannot be done I'd rather refactor 
reasonable sections into separate methods.

> And may all (ex-)C programmers in this group refrain from telling me
> that not initializing variables is dangerous. This is Java, where the
> compiler enforces initialization of variables on all code paths before
> the first read-access to the variable.

Exactly.  And another difference to C is that you can declare variables 
anywhere - not just at the top of the method body.  I have seen too many 
Java methods which did that and used the variable 30 lines below.  That 
really makes reading and understanding code hard.

Cheers

	robert



-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#24744

In article <b2grrlFdgboU1@mid.individual.net>,
Robert Klemme  <shortcutter@googlemail.com> wrote:
> On 20.06.2013 10:23, Sven Köhler wrote:
> > Am 19.06.2013 22:20, schrieb Robert Klemme:

[ snip ]

> > And may all (ex-)C programmers in this group refrain from telling me
> > that not initializing variables is dangerous. This is Java, where the
> > compiler enforces initialization of variables on all code paths before
> > the first read-access to the variable.
> 
> Exactly.  And another difference to C is that you can declare variables 
> anywhere - not just at the top of the method body.  

Well, you can do that in C too, if you use a compiler that supports 
standards later than C89.  Just sayin'.  (And late to the party, as
usual.)

> I have seen too many 
> Java methods which did that and used the variable 30 lines below.  That 
> really makes reading and understanding code hard.

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

[toc] | [prev] | [next] | [standalone]

#24468

On 18/06/13 23:56, Eric Sosman wrote:
> On 6/18/2013 6:38 PM, Joerg Meier wrote:
>> [...]
>> Frankly, I'm surprised that even though it should be obvious that my code
>> was no more supposed to be production code for a method that simple,my
>>
>> "if (x) return true"
>>
>> faced so much more ridicule than lipskas
>>
>> "boolean var; if (x) var = true; return var",
>>
>> which is basically the same only even more verbose.
>
>      Perhaps you attract more ridicule because your posts have a
> wider readership than lipska's.  That explains my reaction, at
> any rate.

Ha ha, not bad, better that your last attempt at a sleight in c.l.c
at any rate, that was very clumsy.

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#24467

On 18/06/13 23:38, Joerg Meier wrote:
> On Mon, 17 Jun 2013 14:49:38 -0400, Eric Sosman wrote:
>
>> On 6/17/2013 2:32 PM, Joerg Meier wrote:
>>> [...]
>>> Personally, I found your example considerably harder to read than the one
>>> liner, as well as harder to read than what would have been my solution:
>>>
>>> private boolean askYesNoquestion (String str){
>>>       if(str.equals("yes"))
>>>           return true;
>>>
>>>       return false;
>>> }
>>       Or, for even greater clarity:
>
> Obviously, in the case of booleans, this style is superfleous (and
> especially in something this simple), but I was trying to demonstrate the
> style, not write a better askYesNoquestion method.
>
> However, as for returning true/false instead of expressions, while this
> would be possible in this extremely simple example, the moment you have
> more conditions, you end up either writing something hard to read with lots
> of && and ||, or you end up with duplicate expressions, or you can go with
> returning true/false.
>
> I don't find "return (((x && y) || a && (z || v)) && c);" to be terribly
> readable. "Exploding" that into a more verbose if/else structure often ends
> up making code a lot more maintainable than the 'every extra letter must be
> conserved' school of thinking.
>
> Frankly, I'm surprised that even though it should be obvious that my code
> was no more supposed to be production code for a method that simple,my
>
> "if (x) return true"
>
> faced so much more ridicule than lipskas
>
> "boolean var; if (x) var = true; return var",
>
> which is basically the same only even more verbose.

but that's not what I wrote, and yes, I understand you were generalizing

What I actually wrote was

boolean response = false;
if(str.equals("yes")){
    response = true;
}
return response;

let's analyze this (lack of error handling notwithstanding)

first we give a sensible name to the variable,
one that reflects it's existential imperative.

then we have our conditional expression. This is surrounded by braces, 
always. If not you get something like this

if(str.equals("yes"))
    return true;
    return false;

Look familiar?

Finally we have our single return statement.

There is more to coding defensively than simply handling Exceptions

Defensive coding is also about making code easy to read, explicit, 
unambiguous down the line and not 'too clever by half' so that future 
maintenance is made impossible or at least very expensive.

Obviously this whole concept is lost on some people who prefer to resort 
to ever more absurd and contrived examples to show how jolly clever they 
are.

I makes me angry because I've spent countless miserable hours trying to 
unravel shitty spaghetti code written by ego driven idiots. If I had my 
way software engineering would be a professional discipline with formal 
qualifications, maybe then we would be rid of the egomaniacs that blight 
our lives with moronic 'optimizations'.

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#24642

On 6/19/2013 4:11 AM, lipska the kat wrote:
> On 18/06/13 23:38, Joerg Meier wrote:
>> On Mon, 17 Jun 2013 14:49:38 -0400, Eric Sosman wrote:
>>
>>> On 6/17/2013 2:32 PM, Joerg Meier wrote:
>>>> [...]
>>>> Personally, I found your example considerably harder to read than
>>>> the one
>>>> liner, as well as harder to read than what would have been my solution:
>>>>
>>>> private boolean askYesNoquestion (String str){
>>>>       if(str.equals("yes"))
>>>>           return true;
>>>>
>>>>       return false;
>>>> }
>>>       Or, for even greater clarity:
>>
>> Obviously, in the case of booleans, this style is superfleous (and
>> especially in something this simple), but I was trying to demonstrate the
>> style, not write a better askYesNoquestion method.
>>
>> However, as for returning true/false instead of expressions, while this
>> would be possible in this extremely simple example, the moment you have
>> more conditions, you end up either writing something hard to read with
>> lots
>> of && and ||, or you end up with duplicate expressions, or you can go
>> with
>> returning true/false.
>>
>> I don't find "return (((x && y) || a && (z || v)) && c);" to be terribly
>> readable. "Exploding" that into a more verbose if/else structure often
>> ends
>> up making code a lot more maintainable than the 'every extra letter
>> must be
>> conserved' school of thinking.
>>
>> Frankly, I'm surprised that even though it should be obvious that my code
>> was no more supposed to be production code for a method that simple,my
>>
>> "if (x) return true"
>>
>> faced so much more ridicule than lipskas
>>
>> "boolean var; if (x) var = true; return var",
>>
>> which is basically the same only even more verbose.
>
> but that's not what I wrote, and yes, I understand you were generalizing
>
> What I actually wrote was
>
> boolean response = false;
> if(str.equals("yes")){
>     response = true;
> }
> return response;
>
> let's analyze this (lack of error handling notwithstanding)
>
> first we give a sensible name to the variable,
> one that reflects it's existential imperative.
>
> then we have our conditional expression. This is surrounded by braces,
> always. If not you get something like this
>
> if(str.equals("yes"))
>     return true;
>     return false;
>
> Look familiar?
>
> Finally we have our single return statement.
>
> There is more to coding defensively than simply handling Exceptions
>
> Defensive coding is also about making code easy to read, explicit,
> unambiguous down the line and not 'too clever by half' so that future
> maintenance is made impossible or at least very expensive.

The above has nothing to do with defensive coding. It does
not protect against anything that the simple:

return str.equals("yes");

does not protect against.

And it is not more readable. It takes longer time
to read.

The one-liner consist of 2 items (evaluate equals, return).

The long version has the same 2 items plus 2 more items
(variable declaration, if statement).

Arne

[toc] | [prev] | [next] | [standalone]

#24645

On 05/07/13 04:11, Arne Vajhøj wrote:
> On 6/19/2013 4:11 AM, lipska the kat wrote:
>> On 18/06/13 23:38, Joerg Meier wrote:
>>> On Mon, 17 Jun 2013 14:49:38 -0400, Eric Sosman wrote:
>>>
>>>> On 6/17/2013 2:32 PM, Joerg Meier wrote:
>>>>> [...]
>>>>> Personally, I found your example considerably harder to read than
>>>>> the one
>>>>> liner, as well as harder to read than what would have been my
>>>>> solution:
>>>>>
>>>>> private boolean askYesNoquestion (String str){
>>>>>       if(str.equals("yes"))
>>>>>           return true;
>>>>>
>>>>>       return false;
>>>>> }
>>>>       Or, for even greater clarity:
>>>
>>> Obviously, in the case of booleans, this style is superfleous (and
>>> especially in something this simple), but I was trying to demonstrate
>>> the
>>> style, not write a better askYesNoquestion method.
>>>
>>> However, as for returning true/false instead of expressions, while this
>>> would be possible in this extremely simple example, the moment you have
>>> more conditions, you end up either writing something hard to read with
>>> lots
>>> of && and ||, or you end up with duplicate expressions, or you can go
>>> with
>>> returning true/false.
>>>
>>> I don't find "return (((x && y) || a && (z || v)) && c);" to be terribly
>>> readable. "Exploding" that into a more verbose if/else structure often
>>> ends
>>> up making code a lot more maintainable than the 'every extra letter
>>> must be
>>> conserved' school of thinking.
>>>
>>> Frankly, I'm surprised that even though it should be obvious that my
>>> code
>>> was no more supposed to be production code for a method that simple,my
>>>
>>> "if (x) return true"
>>>
>>> faced so much more ridicule than lipskas
>>>
>>> "boolean var; if (x) var = true; return var",
>>>
>>> which is basically the same only even more verbose.
>>
>> but that's not what I wrote, and yes, I understand you were generalizing
>>
>> What I actually wrote was
>>
>> boolean response = false;
>> if(str.equals("yes")){
>>     response = true;
>> }
>> return response;
>>
>> let's analyze this (lack of error handling notwithstanding)
>>
>> first we give a sensible name to the variable,
>> one that reflects it's existential imperative.
>>
>> then we have our conditional expression. This is surrounded by braces,
>> always. If not you get something like this
>>
>> if(str.equals("yes"))
>>     return true;
>>     return false;
>>
>> Look familiar?
>>
>> Finally we have our single return statement.
>>
>> There is more to coding defensively than simply handling Exceptions
>>
>> Defensive coding is also about making code easy to read, explicit,
>> unambiguous down the line and not 'too clever by half' so that future
>> maintenance is made impossible or at least very expensive.
>
> The above has nothing to do with defensive coding. It does
> not protect against anything that the simple:

For goodness sake *read the post*

I said 'lack of error handling notwithstanding'

Do you understand what that means?

Do you want an example of defensive coding?

READ THIS FIRST
This is an *example* ... got that, good.

and no, I haven't compiled it and no, I wouldn't normally hard code 
messages in this way (jeez)

Now then

private boolean askYesNoquestion (String str) throws BadArgumentException{

    boolean result = false;

    if(null == str){
        logger.log("Argument is null");
        throw new BadArgumentException("Argument is null");
    }
    else{
        if(str.equals("yes")){
           result = true;
        }
        else if(!str.equals("no")){
            logger.log("Incorrect Argument, argument is " + str);
            throw new BadArgumentException("argument is " + str);
        }
    }
    return result;
}

This is *one* way of doing it

Overkill ... no, defensive yes.

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#24665

On 05.07.2013 10:13, lipska the kat wrote:
> On 05/07/13 04:11, Arne Vajhøj wrote:

>> The above has nothing to do with defensive coding. It does
>> not protect against anything that the simple:
>
> For goodness sake *read the post*
>
> I said 'lack of error handling notwithstanding'
>
> Do you understand what that means?
>
> Do you want an example of defensive coding?
>
> READ THIS FIRST
> This is an *example* ... got that, good.

Funny thing is that people will only see in an example what is presented 
in the example.  So if there is an example which leaves place for 
specific error handling and that error handling is not included people 
won't see it.  They just see a method with unnecessary complexity.

Maybe you'll say it's not easy to pick a good example.  But examples are 
there for a reason: they are used as tools to communicate something.  If 
they fail to do that they should be improved or left out.

> and no, I haven't compiled it and no, I wouldn't normally hard code
> messages in this way (jeez)
>
> Now then
>
> private boolean askYesNoquestion (String str) throws BadArgumentException{
>
>     boolean result = false;
>
>     if(null == str){
>         logger.log("Argument is null");
>         throw new BadArgumentException("Argument is null");
>     }
>     else{
>         if(str.equals("yes")){
>            result = true;
>         }
>         else if(!str.equals("no")){
>             logger.log("Incorrect Argument, argument is " + str);
>             throw new BadArgumentException("argument is " + str);
>         }
>     }
>     return result;
> }
>
> This is *one* way of doing it
>
> Overkill ... no, defensive yes.

This example demonstrates what I will call bad practice: the exception 
is thrown so the calling code can decide how to handle the error.  It 
may actually be that the caller can perfectly deal with that situation 
and proceed normally.  Method askYesNoquestion() cannot know this.  But 
because the method does the logging itself you'll end up seeing messages 
in a log file for things which are not noteworthy.  I say, either log 
and deal with the error locally OR throw an exception containing a 
meaningful message - but not both.  That is misleading.

Cheers

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#24673

On 7/5/2013 5:15 PM, Robert Klemme wrote:
> On 05.07.2013 10:13, lipska the kat wrote:
>> private boolean askYesNoquestion (String str) throws
>> BadArgumentException{
>>
>>     boolean result = false;
>>
>>     if(null == str){
>>         logger.log("Argument is null");
>>         throw new BadArgumentException("Argument is null");
>>     }
>>     else{
>>         if(str.equals("yes")){
>>            result = true;
>>         }
>>         else if(!str.equals("no")){
>>             logger.log("Incorrect Argument, argument is " + str);
>>             throw new BadArgumentException("argument is " + str);
>>         }
>>     }
>>     return result;
>> }
>>
>> This is *one* way of doing it
>>
>> Overkill ... no, defensive yes.
>
> This example demonstrates what I will call bad practice: the exception
> is thrown so the calling code can decide how to handle the error.  It
> may actually be that the caller can perfectly deal with that situation
> and proceed normally.  Method askYesNoquestion() cannot know this.  But
> because the method does the logging itself you'll end up seeing messages
> in a log file for things which are not noteworthy.  I say, either log
> and deal with the error locally OR throw an exception containing a
> meaningful message - but not both.  That is misleading.

I do not agree with the last point.

If we look at the matrix:

            caller logs                     caller do not log
log        insignificant extra log entry   fine
not log    fine                            big problem troubleshooting

then it seems obvious to me to log anyway. Worst case by logging
is not nearly as bad as worst case not logging.

Arne

[toc] | [prev] | [next] | [standalone]

#24676

On 06.07.2013 04:03, Arne Vajhøj wrote:
> On 7/5/2013 5:15 PM, Robert Klemme wrote:
>> On 05.07.2013 10:13, lipska the kat wrote:
>>> private boolean askYesNoquestion (String str) throws
>>> BadArgumentException{
>>>
>>>     boolean result = false;
>>>
>>>     if(null == str){
>>>         logger.log("Argument is null");
>>>         throw new BadArgumentException("Argument is null");
>>>     }
>>>     else{
>>>         if(str.equals("yes")){
>>>            result = true;
>>>         }
>>>         else if(!str.equals("no")){
>>>             logger.log("Incorrect Argument, argument is " + str);
>>>             throw new BadArgumentException("argument is " + str);
>>>         }
>>>     }
>>>     return result;
>>> }
>>>
>>> This is *one* way of doing it
>>>
>>> Overkill ... no, defensive yes.
>>
>> This example demonstrates what I will call bad practice: the exception
>> is thrown so the calling code can decide how to handle the error.  It
>> may actually be that the caller can perfectly deal with that situation
>> and proceed normally.  Method askYesNoquestion() cannot know this.  But
>> because the method does the logging itself you'll end up seeing messages
>> in a log file for things which are not noteworthy.  I say, either log
>> and deal with the error locally OR throw an exception containing a
>> meaningful message - but not both.  That is misleading.
>
> I do not agree with the last point.
>
> If we look at the matrix:
>
>             caller logs                     caller do not log
> log        insignificant extra log entry   fine

I do not agree to the "insignificant".

> not log    fine                            big problem troubleshooting
>
> then it seems obvious to me to log anyway. Worst case by logging
> is not nearly as bad as worst case not logging.

Maybe I haven't made myself clear enough: it is the task of the writer 
of the calling code to decide whether the exception is a problem or not. 
  This decision cannot be done by the author of this method.  Presumably 
this is a low level method which is invoked from many different places 
and so some may be able to handle the exception while some may not. 
Since a RuntimeException (NPE is one) will be likely caught somewhere 
high up the call chain and logged there (usually with the stack trace) 
debugging should not be too difficult.  If on the other hand you need to 
wade through tons of log messages which do not signal an error then 
debugging is also harmed.  Not to mention the additional IO overhead for 
all the superfluous log messages.

Cheers

	robert



-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#24679

On 06/07/13 12:01, Robert Klemme wrote:
> On 06.07.2013 04:03, Arne Vajhøj wrote:
>> On 7/5/2013 5:15 PM, Robert Klemme wrote:
>>> On 05.07.2013 10:13, lipska the kat wrote:
>>>> private boolean askYesNoquestion (String str) throws
>>>> BadArgumentException{
>>>>
>>>>     boolean result = false;
>>>>
>>>>     if(null == str){
>>>>         logger.log("Argument is null");
>>>>         throw new BadArgumentException("Argument is null");
>>>>     }
>>>>     else{
>>>>         if(str.equals("yes")){
>>>>            result = true;
>>>>         }
>>>>         else if(!str.equals("no")){
>>>>             logger.log("Incorrect Argument, argument is " + str);
>>>>             throw new BadArgumentException("argument is " + str);
>>>>         }
>>>>     }
>>>>     return result;
>>>> }
>>>>
>>>> This is *one* way of doing it
>>>>
>>>> Overkill ... no, defensive yes.
>>>
>>> This example demonstrates what I will call bad practice: the exception
>>> is thrown so the calling code can decide how to handle the error.  It
>>> may actually be that the caller can perfectly deal with that situation
>>> and proceed normally.  Method askYesNoquestion() cannot know this.  But
>>> because the method does the logging itself you'll end up seeing messages
>>> in a log file for things which are not noteworthy.  I say, either log
>>> and deal with the error locally OR throw an exception containing a
>>> meaningful message - but not both.  That is misleading.
>>
>> I do not agree with the last point.
>>
>> If we look at the matrix:
>>
>>             caller logs                     caller do not log
>> log        insignificant extra log entry   fine
>
> I do not agree to the "insignificant".
>
>> not log    fine                            big problem troubleshooting
>>
>> then it seems obvious to me to log anyway. Worst case by logging
>> is not nearly as bad as worst case not logging.
>
> Maybe I haven't made myself clear enough: it is the task of the writer
> of the calling code to decide whether the exception is a problem or not.
>   This decision cannot be done by the author of this method.

The author has determined that certain conditions are exceptional
Who else but the author is qualified to make such a decision?

It's not up to caller "to decide whether the exception is a problem or 
not" If there was no problem then there would be no exception.

It's up to the client to decide how to handle it ... a situation over 
which the original author has no control.

And this is the point, If I write a method that will be used by others 
outside my sphere of influence and that method throws an exception then 
as the author I would want to know what was going on, I sure as hell 
wouldn't look hopefully towards the client to see if they know why my 
black box component was throwing an exception. They would expect to see 
some logging ... I would too in the same situation.

> Presumably
> this is a low level method which is invoked from many different places
> and so some may be able to handle the exception while some may not.
> Since a RuntimeException (NPE is one) will be likely caught somewhere
> high up the call chain and logged there (usually with the stack trace)
> debugging should not be too difficult.  If on the other hand you need to
> wade through tons of log messages which do not signal an error

Show me where I log anything that is not an error.

if the argument is null that is an error. Log the error at the point of 
origin. Inform the client by throwing an exception

if the argument is yes then no logging occurs and the result is set to true

if the argument is no then no logging occurs, the default is returned

If the result is not yes or no and it's not null then that is an error
Log the error at the point of origin. Inform the client by throwing an 
exception.

> then debugging is also harmed.  Not to mention the additional IO overhead for
> all the superfluous log messages.

There is no such thing IME, any decent logging framework is configurable 
by level.

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#24682

On Sat, 06 Jul 2013 13:01:56 +0200, Robert Klemme wrote:

> On 06.07.2013 04:03, Arne Vajhøj wrote:
>> On 7/5/2013 5:15 PM, Robert Klemme wrote:
>>> On 05.07.2013 10:13, lipska the kat wrote:
>>>> private boolean askYesNoquestion (String str) throws
>>>> BadArgumentException{
>>>>
>>>>     boolean result = false;
>>>>
>>>>     if(null == str){
>>>>         logger.log("Argument is null");
>>>>         throw new BadArgumentException("Argument is null");
>>>>     }
>>>>     else{
>>>>         if(str.equals("yes")){
>>>>            result = true;
>>>>         }
>>>>         else if(!str.equals("no")){
>>>>             logger.log("Incorrect Argument, argument is " + str);
>>>>             throw new BadArgumentException("argument is " + str);
>>>>         }
>>>>     }
>>>>     return result;
>>>> }
>>>>
>>>> This is *one* way of doing it
>>>>
>>>> Overkill ... no, defensive yes.
>>>
>>> This example demonstrates what I will call bad practice: the exception
>>> is thrown so the calling code can decide how to handle the error.  It
>>> may actually be that the caller can perfectly deal with that situation
>>> and proceed normally.  Method askYesNoquestion() cannot know this. 
>>> But because the method does the logging itself you'll end up seeing
>>> messages in a log file for things which are not noteworthy.  I say,
>>> either log and deal with the error locally OR throw an exception
>>> containing a meaningful message - but not both.  That is misleading.
>>
>> I do not agree with the last point.
>>
>> If we look at the matrix:
>>
>>             caller logs                     caller do not log
>> log        insignificant extra log entry   fine
> 
> I do not agree to the "insignificant".
> 
>> not log    fine                            big problem troubleshooting
>>
>> then it seems obvious to me to log anyway. Worst case by logging is not
>> nearly as bad as worst case not logging.
> 
> Maybe I haven't made myself clear enough: it is the task of the writer
> of the calling code to decide whether the exception is a problem or not.
>
Basically the author has two things to do:
1) return valid answers (in this case true for 'yes' and false for 'no'
2) decide what to do with errors, i.e. inputs that can't be easily
   and unambiguously resolved into true or false.

In dealing with the errors I think its worthwhile distinguishing between 
things that happen routinely during a run (in this case and input that 
isn't "yes" or "no") that the calling code is expected to deal with as 
part of its normal operation and less common stuff (e.g being handed a 
null pointer rather than a String instance. This distinction makes 
writing the caller much easier. 

So, in this case, I'd probably reserve use of an exception for dealing 
with a null and add a third return code for the wrong string value, 
because this lets the caller write something like:

   Prompter p = new Prompter("Is it teatime yet");
   char answer = Prompter.BAD_REPLY;
   try 
   {
      while (answer == Prompter.BAD_REPLY)
         answer = p.getResponse();
   }
   catch (PrompterException e)
   {
      logger.abandon("Error: " + e.getMessage());
   }

   if (answer == Prompter.AFFIRMATIVE)
       ......;
   else
       ......;

I started to use this type of error processing after my first brush with 
PL/1, where the i/o system throws exceptions for everything from real 
exceptions such as file not found or disk errors, when you want to stop 
the run, and expected events such as end of file or key not found, which 
need to be handled within the normal logic flow. I found that the need to 
go through an exception handler just to deal with normal events such as 
end of file made the logic harder to follow because in PL/1 there's 
nothing like the try..catch block: about all you can do is like this:

dcl EOF char(1) init('N');
on endfile(file1) EOF = 'Y';

do while(EOF = 'N')
begin
   read file(file1) into(inputrec);
   .....
end

Consequently, I tend to write Java such that expected events in a method 
call will return a value indicating success or failure and the method 
will only throw an Exception when the best thing the program can do is 
quit. The need to use a getter to retrieve the expected result seems like 
a worthwhile price to pay the cleaner logic flow in the calling code.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#24684

On 7/6/2013 7:01 AM, Robert Klemme wrote:
> On 06.07.2013 04:03, Arne Vajhøj wrote:
>> On 7/5/2013 5:15 PM, Robert Klemme wrote:
>>> On 05.07.2013 10:13, lipska the kat wrote:
>>>> private boolean askYesNoquestion (String str) throws
>>>> BadArgumentException{
>>>>
>>>>     boolean result = false;
>>>>
>>>>     if(null == str){
>>>>         logger.log("Argument is null");
>>>>         throw new BadArgumentException("Argument is null");
>>>>     }
>>>>     else{
>>>>         if(str.equals("yes")){
>>>>            result = true;
>>>>         }
>>>>         else if(!str.equals("no")){
>>>>             logger.log("Incorrect Argument, argument is " + str);
>>>>             throw new BadArgumentException("argument is " + str);
>>>>         }
>>>>     }
>>>>     return result;
>>>> }
>>>>
>>>> This is *one* way of doing it
>>>>
>>>> Overkill ... no, defensive yes.
>>>
>>> This example demonstrates what I will call bad practice: the exception
>>> is thrown so the calling code can decide how to handle the error.  It
>>> may actually be that the caller can perfectly deal with that situation
>>> and proceed normally.  Method askYesNoquestion() cannot know this.  But
>>> because the method does the logging itself you'll end up seeing messages
>>> in a log file for things which are not noteworthy.  I say, either log
>>> and deal with the error locally OR throw an exception containing a
>>> meaningful message - but not both.  That is misleading.
>>
>> I do not agree with the last point.
>>
>> If we look at the matrix:
>>
>>             caller logs                     caller do not log
>> log        insignificant extra log entry   fine
>
> I do not agree to the "insignificant".

It is just an extra log entry.

Whether the log file is 100 MB or 110 MB does not really change anything.

>
>> not log    fine                            big problem troubleshooting
>>
>> then it seems obvious to me to log anyway. Worst case by logging
>> is not nearly as bad as worst case not logging.
>
> Maybe I haven't made myself clear enough: it is the task of the writer
> of the calling code to decide whether the exception is a problem or not.

Yes. That is somewhat orthogonal to whether to log or not.

>   This decision cannot be done by the author of this method.  Presumably
> this is a low level method which is invoked from many different places
> and so some may be able to handle the exception while some may not.
> Since a RuntimeException (NPE is one) will be likely caught somewhere
> high up the call chain and logged there (usually with the stack trace)
> debugging should not be too difficult.  If on the other hand you need to
> wade through tons of log messages which do not signal an error then
> debugging is also harmed.  Not to mention the additional IO overhead for
> all the superfluous log messages.

Assuming that somebody else will do the right thing show good faith
in mankind but is still not a recommended way to design software.

Developers are humans and humans make mistakes. Don't assume that other
developers always do what they are supposed to do. They may do it 99% of
cases but in 1% of cases they do not get it right - bad day or something.

Arne

[toc] | [prev] | [next] | [standalone]

#24687

On 06/07/13 21:18, Arne Vajhøj wrote:
> On 7/6/2013 7:01 AM, Robert Klemme wrote:
>> On 06.07.2013 04:03, Arne Vajhøj wrote:
>>> On 7/5/2013 5:15 PM, Robert Klemme wrote:
>>>> On 05.07.2013 10:13, lipska the kat wrote:
>>>>> private boolean askYesNoquestion (String str) throws
>>>>> BadArgumentException{
>>>>>
>>>>>     boolean result = false;
>>>>>
>>>>>     if(null == str){
>>>>>         logger.log("Argument is null");
>>>>>         throw new BadArgumentException("Argument is null");
>>>>>     }
>>>>>     else{
>>>>>         if(str.equals("yes")){
>>>>>            result = true;
>>>>>         }
>>>>>         else if(!str.equals("no")){
>>>>>             logger.log("Incorrect Argument, argument is " + str);
>>>>>             throw new BadArgumentException("argument is " + str);
>>>>>         }
>>>>>     }
>>>>>     return result;
>>>>> }
>>>>>
>>>>> This is *one* way of doing it
>>>>>
>>>>> Overkill ... no, defensive yes.
>>>>
>>>> This example demonstrates what I will call bad practice: the exception
>>>> is thrown so the calling code can decide how to handle the error.  It
>>>> may actually be that the caller can perfectly deal with that situation
>>>> and proceed normally.  Method askYesNoquestion() cannot know this.  But
>>>> because the method does the logging itself you'll end up seeing
>>>> messages
>>>> in a log file for things which are not noteworthy.  I say, either log
>>>> and deal with the error locally OR throw an exception containing a
>>>> meaningful message - but not both.  That is misleading.
>>>
>>> I do not agree with the last point.
>>>
>>> If we look at the matrix:
>>>
>>>             caller logs                     caller do not log
>>> log        insignificant extra log entry   fine
>>
>> I do not agree to the "insignificant".
>
> It is just an extra log entry.
>
> Whether the log file is 100 MB or 110 MB does not really change anything.
>
>>
>>> not log    fine                            big problem troubleshooting
>>>
>>> then it seems obvious to me to log anyway. Worst case by logging
>>> is not nearly as bad as worst case not logging.
>>
>> Maybe I haven't made myself clear enough: it is the task of the writer
>> of the calling code to decide whether the exception is a problem or not.
>
> Yes. That is somewhat orthogonal to whether to log or not.
>
>>   This decision cannot be done by the author of this method.  Presumably
>> this is a low level method which is invoked from many different places
>> and so some may be able to handle the exception while some may not.
>> Since a RuntimeException (NPE is one) will be likely caught somewhere
>> high up the call chain and logged there (usually with the stack trace)
>> debugging should not be too difficult.  If on the other hand you need to
>> wade through tons of log messages which do not signal an error then
>> debugging is also harmed.  Not to mention the additional IO overhead for
>> all the superfluous log messages.
>
> Assuming that somebody else will do the right thing show good faith
> in mankind but is still not a recommended way to design software.

Blimey Arne ... well said.

<snip>

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#24675

On 05/07/13 22:15, Robert Klemme wrote:
> On 05.07.2013 10:13, lipska the kat wrote:
>> On 05/07/13 04:11, Arne Vajhøj wrote:
>
>>> The above has nothing to do with defensive coding. It does
>>> not protect against anything that the simple:
>>
>> For goodness sake *read the post*
>>
>> I said 'lack of error handling notwithstanding'
>>
>> Do you understand what that means?
>>
>> Do you want an example of defensive coding?
>>
>> READ THIS FIRST
>> This is an *example* ... got that, good.
>
> Funny thing is that people will only see in an example what is presented
> in the example.  So if there is an example which leaves place for
> specific error handling and that error handling is not included people
> won't see it.  They just see a method with unnecessary complexity.
>
> Maybe you'll say it's not easy to pick a good example.  But examples are
> there for a reason: they are used as tools to communicate something.  If
> they fail to do that they should be improved or left out.
>
>> and no, I haven't compiled it and no, I wouldn't normally hard code
>> messages in this way (jeez)
>>
>> Now then
>>
>> private boolean askYesNoquestion (String str) throws
>> BadArgumentException{
>>
>>     boolean result = false;
>>
>>     if(null == str){
>>         logger.log("Argument is null");
>>         throw new BadArgumentException("Argument is null");
>>     }
>>     else{
>>         if(str.equals("yes")){
>>            result = true;
>>         }
>>         else if(!str.equals("no")){
>>             logger.log("Incorrect Argument, argument is " + str);
>>             throw new BadArgumentException("argument is " + str);
>>         }
>>     }
>>     return result;
>> }
>>
>> This is *one* way of doing it
>>
>> Overkill ... no, defensive yes.
>
> This example demonstrates what I will call bad practice: the exception
> is thrown so the calling code can decide how to handle the error.
> It may actually be that the caller can perfectly deal with that situation
> and proceed normally.  Method askYesNoquestion() cannot know this.  But
> because the method does the logging itself you'll end up seeing messages
> in a log file for things which are not noteworthy.  I say, either log
> and deal with the error locally OR throw an exception containing a
> meaningful message - but not both.  That is misleading.

Frankly I think you are missing the whole point of defensive programming.

You yourself said

"It may actually be that the caller can perfectly deal with that 
situation..."

The important word here is *may* ... what happens if the caller decides 
to ignore the exception, or maybe handle it without recording the 
reason. What are you left with ...

The example is trivial I agree but the concept is sound.

... and who says these things are not *noteworthy*. If you are 
programming defensively then *everything* is noteworthy.

IMHO it is bad practice *not* to log the error at the point of origin.

There's an old adage in this business "You can never have too much data"
This is especially true when programing defensively.

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#24677

On 06.07.2013 10:16, lipska the kat wrote:
> On 05/07/13 22:15, Robert Klemme wrote:
>> On 05.07.2013 10:13, lipska the kat wrote:
>>> On 05/07/13 04:11, Arne Vajhøj wrote:
>>
>>>> The above has nothing to do with defensive coding. It does
>>>> not protect against anything that the simple:
>>>
>>> For goodness sake *read the post*
>>>
>>> I said 'lack of error handling notwithstanding'
>>>
>>> Do you understand what that means?
>>>
>>> Do you want an example of defensive coding?
>>>
>>> READ THIS FIRST
>>> This is an *example* ... got that, good.
>>
>> Funny thing is that people will only see in an example what is presented
>> in the example.  So if there is an example which leaves place for
>> specific error handling and that error handling is not included people
>> won't see it.  They just see a method with unnecessary complexity.
>>
>> Maybe you'll say it's not easy to pick a good example.  But examples are
>> there for a reason: they are used as tools to communicate something.  If
>> they fail to do that they should be improved or left out.
>>
>>> and no, I haven't compiled it and no, I wouldn't normally hard code
>>> messages in this way (jeez)
>>>
>>> Now then
>>>
>>> private boolean askYesNoquestion (String str) throws
>>> BadArgumentException{
>>>
>>>     boolean result = false;
>>>
>>>     if(null == str){
>>>         logger.log("Argument is null");
>>>         throw new BadArgumentException("Argument is null");
>>>     }
>>>     else{
>>>         if(str.equals("yes")){
>>>            result = true;
>>>         }
>>>         else if(!str.equals("no")){
>>>             logger.log("Incorrect Argument, argument is " + str);
>>>             throw new BadArgumentException("argument is " + str);
>>>         }
>>>     }
>>>     return result;
>>> }
>>>
>>> This is *one* way of doing it
>>>
>>> Overkill ... no, defensive yes.
>>
>> This example demonstrates what I will call bad practice: the exception
>> is thrown so the calling code can decide how to handle the error.
>> It may actually be that the caller can perfectly deal with that situation
>> and proceed normally.  Method askYesNoquestion() cannot know this.  But
>> because the method does the logging itself you'll end up seeing messages
>> in a log file for things which are not noteworthy.  I say, either log
>> and deal with the error locally OR throw an exception containing a
>> meaningful message - but not both.  That is misleading.
>
> Frankly I think you are missing the whole point of defensive programming.
>
> You yourself said
>
> "It may actually be that the caller can perfectly deal with that
> situation..."
>
> The important word here is *may* ... what happens if the caller decides
> to ignore the exception, or maybe handle it without recording the
> reason. What are you left with ...

Well, you can forget the logging on *any* level of the application. 
There is no really a difference between asking the author of this method 
to do proper error handling or asking the author of some other code to 
do it.

> The example is trivial I agree but the concept is sound.

If you do that kind of logging in all sorts of methods you'll end up 
with extreme volumes of logfiles that make it hard to detect real bugs 
and cost significant IO.

> ... and who says these things are not *noteworthy*. If you are
> programming defensively then *everything* is noteworthy.

For me "defensive programming" in this example means to check arguments 
and throw NPE or IllegalArgumentException if the data passed into the 
method violates the specified (e.g. in JavaDoc) contract.  Nothing more. 
  Errors will show up.  If the caller does not handle exceptions 
properly then the exception will show up somewhere up the call stack 
where it's logged or presented to the user.  Easy to find bugs then.

> IMHO it is bad practice *not* to log the error at the point of origin.

The point is: you do not know whether it _is_ an error inside this 
method.  You know arguments violate the contract, but you do not know 
whether that poses a problem for the program.  Hence: throw an exception 
and be done.

> There's an old adage in this business "You can never have too much data"
> This is especially true when programing defensively.

I disagree.

Cheers

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web