Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #24417 > unrolled thread
| Started by | rajbhaumik@gmail.com |
|---|---|
| First post | 2013-06-15 13:38 -0700 |
| Last post | 2013-06-18 04:06 -0400 |
| Articles | 20 on this page of 103 — 16 participants |
Back to article view | Back to comp.lang.java.programmer
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 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2013-07-06 08:22 -0400 |
| Message-ID | <kr91rv$icl$1@dont-email.me> |
| In reply to | #24677 |
On 7/6/2013 7:14 AM, Robert Klemme wrote:
> [...]
> 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 caller has more context. When Integer.parseInt() is
unable to make sense of the input string, it has no way of knowing
whether the failure is fatal, unusual, or expected. Do you think
it should log all such failures in addition to throwing up?
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | Robert Klemme <shortcutter@googlemail.com> |
|---|---|
| Date | 2013-07-07 20:43 +0200 |
| Message-ID | <b3tr78F5si6U1@mid.individual.net> |
| In reply to | #24678 |
On 06.07.2013 14:22, Eric Sosman wrote: > On 7/6/2013 7:14 AM, Robert Klemme wrote: >> [...] >> 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 caller has more context. When Integer.parseInt() is > unable to make sense of the input string, it has no way of knowing > whether the failure is fatal, unusual, or expected. Do you think > it should log all such failures in addition to throwing up? No. That is exactly my point. Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2013-07-07 18:07 -0400 |
| Message-ID | <krcog3$mlm$1@dont-email.me> |
| In reply to | #24692 |
On 7/7/2013 2:43 PM, Robert Klemme wrote:
> On 06.07.2013 14:22, Eric Sosman wrote:
>> On 7/6/2013 7:14 AM, Robert Klemme wrote:
>>> [...]
>>> 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 caller has more context. When Integer.parseInt() is
>> unable to make sense of the input string, it has no way of knowing
>> whether the failure is fatal, unusual, or expected. Do you think
>> it should log all such failures in addition to throwing up?
>
> No. That is exactly my point.
Okay, you've confused me. I maintain that the caller has more
context than the callee, and is therefore (often) in a better position
to make wider-scope decisions in handling errors. That, it seems to
me, is a distinct and notable difference in how the errors are handled.
Yet you say "there is really no difference" in handling an error Here
or There (or maybe even Elsewhere). I don't get it.
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-07-07 19:35 -0400 |
| Message-ID | <51d9fb26$0$301$14726298@news.sunsite.dk> |
| In reply to | #24697 |
On 7/7/2013 6:07 PM, Eric Sosman wrote: > On 7/7/2013 2:43 PM, Robert Klemme wrote: >> On 06.07.2013 14:22, Eric Sosman wrote: >>> On 7/6/2013 7:14 AM, Robert Klemme wrote: >>>> [...] >>>> 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 caller has more context. When Integer.parseInt() is >>> unable to make sense of the input string, it has no way of knowing >>> whether the failure is fatal, unusual, or expected. Do you think >>> it should log all such failures in addition to throwing up? >> >> No. That is exactly my point. > > Okay, you've confused me. I maintain that the caller has more > context than the callee, and is therefore (often) in a better position > to make wider-scope decisions in handling errors. That, it seems to > me, is a distinct and notable difference in how the errors are handled. > Yet you say "there is really no difference" in handling an error Here > or There (or maybe even Elsewhere). I don't get it. Before you continue the discussion then maybe you should clarify the topic of discussion: "should called often delegate exception handling to caller" vs "should called often delegate exception logging to caller". Arne
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2013-07-07 20:42 -0400 |
| Message-ID | <krd1it$tj0$1@dont-email.me> |
| In reply to | #24700 |
On 7/7/2013 7:35 PM, Arne Vajhøj wrote:
> On 7/7/2013 6:07 PM, Eric Sosman wrote:
>> On 7/7/2013 2:43 PM, Robert Klemme wrote:
>>> On 06.07.2013 14:22, Eric Sosman wrote:
>>>> On 7/6/2013 7:14 AM, Robert Klemme wrote:
>>>>> [...]
>>>>> 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 caller has more context. When Integer.parseInt() is
>>>> unable to make sense of the input string, it has no way of knowing
>>>> whether the failure is fatal, unusual, or expected. Do you think
>>>> it should log all such failures in addition to throwing up?
>>>
>>> No. That is exactly my point.
>>
>> Okay, you've confused me. I maintain that the caller has more
>> context than the callee, and is therefore (often) in a better position
>> to make wider-scope decisions in handling errors. That, it seems to
>> me, is a distinct and notable difference in how the errors are handled.
>> Yet you say "there is really no difference" in handling an error Here
>> or There (or maybe even Elsewhere). I don't get it.
>
> Before you continue the discussion then maybe you should clarify the
> topic of discussion: "should called often delegate exception handling to
> caller" vs "should called often delegate exception logging to caller".
All right: What are *your* thoughts on Integer.parseInt()
logging every unsuccessful conversion?
(And why limit logging to *un*successful conversions? An
unexpected successful conversion can be just as important, can
it not?)
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | Robert Klemme <shortcutter@googlemail.com> |
|---|---|
| Date | 2013-07-08 20:50 +0200 |
| Message-ID | <b40fvqFnfb6U1@mid.individual.net> |
| In reply to | #24697 |
On 08.07.2013 00:07, Eric Sosman wrote: > On 7/7/2013 2:43 PM, Robert Klemme wrote: >> On 06.07.2013 14:22, Eric Sosman wrote: >>> On 7/6/2013 7:14 AM, Robert Klemme wrote: >>>> [...] >>>> 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 caller has more context. When Integer.parseInt() is >>> unable to make sense of the input string, it has no way of knowing >>> whether the failure is fatal, unusual, or expected. Do you think >>> it should log all such failures in addition to throwing up? >> >> No. That is exactly my point. > > Okay, you've confused me. I maintain that the caller has more > context than the callee, and is therefore (often) in a better position > to make wider-scope decisions in handling errors. That, it seems to > me, is a distinct and notable difference in how the errors are handled. Absolutely. > Yet you say "there is really no difference" in handling an error Here > or There (or maybe even Elsewhere). I don't get it. I just said above that errors by developers happen on every level of an application. If you ask that (error) conditions should be logged on a low level (callee) you can as well ask that errors are handled / logged at the upper level (caller). In light of human beings writing the code they can forget here or there. I said that because the argument was that the logging should be done in the low level method because the caller author may forget it. Does that help to get rid of the confusion? Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2013-07-08 15:01 -0400 |
| Message-ID | <krf209$mmi$1@dont-email.me> |
| In reply to | #24713 |
On 7/8/2013 2:50 PM, Robert Klemme wrote:
> On 08.07.2013 00:07, Eric Sosman wrote:
>> On 7/7/2013 2:43 PM, Robert Klemme wrote:
>>> On 06.07.2013 14:22, Eric Sosman wrote:
>>>> On 7/6/2013 7:14 AM, Robert Klemme wrote:
>>>>> [...]
>>>>> 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 caller has more context. When Integer.parseInt() is
>>>> unable to make sense of the input string, it has no way of knowing
>>>> whether the failure is fatal, unusual, or expected. Do you think
>>>> it should log all such failures in addition to throwing up?
>>>
>>> No. That is exactly my point.
>>
>> Okay, you've confused me. I maintain that the caller has more
>> context than the callee, and is therefore (often) in a better position
>> to make wider-scope decisions in handling errors. That, it seems to
>> me, is a distinct and notable difference in how the errors are handled.
>
> Absolutely.
>
>> Yet you say "there is really no difference" in handling an error Here
>> or There (or maybe even Elsewhere). I don't get it.
>
> I just said above that errors by developers happen on every level of an
> application. If you ask that (error) conditions should be logged on a
> low level (callee) you can as well ask that errors are handled / logged
> at the upper level (caller). In light of human beings writing the code
> they can forget here or there. I said that because the argument was
> that the logging should be done in the low level method because the
> caller author may forget it. Does that help to get rid of the confusion?
Thanks for the clarification. I misunderstood "you can forget"
as a dismissive idiom, as in "forget about it" (or "fuhgeddaboudit")
instead of as "one might forget" or "forgetfulness happens."
I think we agree vehemently.
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | Robert Klemme <shortcutter@googlemail.com> |
|---|---|
| Date | 2013-07-08 23:29 +0200 |
| Message-ID | <b40pa7FpfgaU1@mid.individual.net> |
| In reply to | #24714 |
On 08.07.2013 21:01, Eric Sosman wrote: > On 7/8/2013 2:50 PM, Robert Klemme wrote: >> On 08.07.2013 00:07, Eric Sosman wrote: >>> On 7/7/2013 2:43 PM, Robert Klemme wrote: >>>> On 06.07.2013 14:22, Eric Sosman wrote: >>>>> On 7/6/2013 7:14 AM, Robert Klemme wrote: >>>>>> [...] >>>>>> 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 caller has more context. When Integer.parseInt() is >>>>> unable to make sense of the input string, it has no way of knowing >>>>> whether the failure is fatal, unusual, or expected. Do you think >>>>> it should log all such failures in addition to throwing up? >>>> >>>> No. That is exactly my point. >>> >>> Okay, you've confused me. I maintain that the caller has more >>> context than the callee, and is therefore (often) in a better position >>> to make wider-scope decisions in handling errors. That, it seems to >>> me, is a distinct and notable difference in how the errors are handled. >> >> Absolutely. >> >>> Yet you say "there is really no difference" in handling an error Here >>> or There (or maybe even Elsewhere). I don't get it. >> >> I just said above that errors by developers happen on every level of an >> application. If you ask that (error) conditions should be logged on a >> low level (callee) you can as well ask that errors are handled / logged >> at the upper level (caller). In light of human beings writing the code >> they can forget here or there. I said that because the argument was >> that the logging should be done in the low level method because the >> caller author may forget it. Does that help to get rid of the confusion? > > Thanks for the clarification. I misunderstood "you can forget" > as a dismissive idiom, as in "forget about it" (or "fuhgeddaboudit") > instead of as "one might forget" or "forgetfulness happens." Duh! Thank you for bringing that up. On rereading my wording was indeed quite ambiguous. Amazing how one does not notice - the meaning is of course obvious to the author. :-) > I think we agree vehemently. Yes. Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-07-06 16:27 -0400 |
| Message-ID | <51d87da1$0$290$14726298@news.sunsite.dk> |
| In reply to | #24677 |
On 7/6/2013 7:14 AM, Robert Klemme wrote: > On 06.07.2013 10:16, lipska the kat wrote: >> 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. In all my years working with log4j log files I have never felt that it was a problem with too much logged but often cursed that they did not log exactly what I needed. For anything except the most trivial apps the log files are too big to just read top down. You need to use tools: editor find, grep, special log tools, whatever. And then it really doe snot matter of it is 1 MB, 10 MB, 100 MB or 1 GB. And log files are sequentially written text files. Logging a MB per hour has very little performance impact today. >> 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. Correct. > Hence: throw an exception > and be done. No. Logging is not intended only to be used for errors. If we look at log4j log levels: fatal error warn info debug trace then I agree that because we do not know if it is an error, then we should not use the first 2 levels, but that leaves 4 levels as potential candidates for level. jul has similar multiple levels. Arne
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2013-07-06 13:41 -0700 |
| Message-ID | <c563603a-f06e-42f6-a8e6-207e8601e657@googlegroups.com> |
| In reply to | #24685 |
Arne Vajhøj wrote: > Logging is not intended only to be used for errors. > > If we look at log4j log levels: > > fatal > error > warn > info > debug > trace > > then I agree that because we do not know if it is an error, then > we should not use the first 2 levels, but that leaves 4 levels > as potential candidates for level. > > jul has similar multiple levels. So does the Android 'Log' class. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-07-05 21:59 -0400 |
| Message-ID | <51d77a21$0$294$14726298@news.sunsite.dk> |
| In reply to | #24645 |
On 7/5/2013 4:13 AM, lipska the kat wrote:
> 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?
Actually - yes.
But apparently you do not since you started arguing for your
code referring to defensive coding.
Arne
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <"nospam at neversurrender dot co dot uk"> |
|---|---|
| Date | 2013-06-17 21:06 +0100 |
| Message-ID | <e5ydnbY_Mc2x8SLMnZ2dnUVZ7s2dnZ2d@bt.com> |
| In reply to | #24439 |
On 17/06/13 19:32, Joerg Meier wrote:
> On Mon, 17 Jun 2013 14:46:57 +0100, lipska the kat wrote:
>
>> return str.equals("yes");
>
>> It's lazy coding and harder to understand than my example and yes, I
>> realize that it's only a one liner but the next stage in the
>> 'development' of this style is
>
> 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;
> }
This is just horrible, really. You are having a laugh right?
I mean, you *cannot* be serious man.
If I had to quantify horrible this would be in the mix.
lipska
--
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun
[toc] | [prev] | [next] | [standalone]
| From | Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> |
|---|---|
| Date | 2013-06-17 17:36 -0500 |
| Message-ID | <kpo2oa$j1e$1@dont-email.me> |
| In reply to | #24436 |
On 6/17/2013 8:46 AM, lipska the kat wrote:
> ... and what is your opinion of defensive coding?
The term, as I understand it, refers to coding under the assumption that
everyone who uses your API is a stupid idiot who can't follow your rules
properly. The matter at hand here is basically a stylistic concern about
which is mentally easier to follow, which falls under the category of
"everyone has an opinion which is strongly held and won't be changed."
> This discipline is hard to learn and once learned even harder to
> un-learn. This is why I don't like things like
>
> return str.equals("yes");
>
> It's lazy coding and harder to understand than my example
To you, maybe. To me, no. This kind of one liner immediately indicates
to me that the function is equivalent with the notion that the string is
exactly "yes". In your example, by contrast, that equivalence is not
obvious: it says that the answer is false unless the string is exactly
"yes", and uncovering the functional equivalence requires resolving a
double-negative.
> if(something){
> return something;
> }
> else if(something else){
> return something else;
> }
> else{
> return some other value
> }
>
> It is much easier to understand and debug
> the following
Style wars much? To me, personally, early-return is often valuable,
especially in languages like C++ or Java which have useful constructs
for handling post-call cleanup such as RAII or try-finally blocks. I'm
going to stop short of saying I prefer early-return, since it is very
much a decision that applies in a specific context, and these examples
are all trying to apply a universally generic rule.
An example of my preferred code style would be something like this (the
comments preceding most of those blocks of code are necessary in this
style--if how you got there isn't trivially obvious, explain what it
means to get there):
Frabnaz getResourceFromKey(String key) {
// Normalize the key so we know exactly how to refer to it in our
// caches.
key = normalize(key);
if (!isValid(key))
throw new IllegalArgumentException(...);
// We have a hyper-optimized variant of this if we know this is
// already on a local filesystem
if (isLocalFile(key))
return getLocalFileResource(key);
// This resource must be on the network. To keep this from killing
// performance, cache uses...
MagicCache cache = foobarToGrabTheCache();
if (cache.hasResource(key))
return cache.getResource(key);
// Can't find it in the cache, so download it but save off a copy
// in the cache.
Frabnaz result = getResourceFromNet(key);
cache.putResource(key, result);
return result;
}
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
[toc] | [prev] | [next] | [standalone]
| From | Robert Klemme <shortcutter@googlemail.com> |
|---|---|
| Date | 2013-06-18 08:24 +0200 |
| Message-ID | <b2acppFo11U1@mid.individual.net> |
| In reply to | #24445 |
On 18.06.2013 00:36, Joshua Cranmer 🐧 wrote:
> On 6/17/2013 8:46 AM, lipska the kat wrote:
>> ... and what is your opinion of defensive coding?
>
> The term, as I understand it, refers to coding under the assumption that
> everyone who uses your API is a stupid idiot who can't follow your rules
> properly. The matter at hand here is basically a stylistic concern about
> which is mentally easier to follow, which falls under the category of
> "everyone has an opinion which is strongly held and won't be changed."
I would say though that - as a rule of thumb - the less decision points
there are in a method the easier it is to read. Of course, there are
always degenerate cases but this is certainly not one of them.
>> This discipline is hard to learn and once learned even harder to
>> un-learn. This is why I don't like things like
>>
>> return str.equals("yes");
>>
>> It's lazy coding and harder to understand than my example
That's not lazy. Looking through the real intent of the code and
stripping the code down to exactly the minimal readable solution is more
work than just applying if else. For me, _that_ is lazy coding: it's
much simpler to hack something that "just works" than to think about the
problem to solve more and come up with a more structured and more
concise solution.
> To you, maybe. To me, no. This kind of one liner immediately indicates
> to me that the function is equivalent with the notion that the string is
> exactly "yes". In your example, by contrast, that equivalence is not
> obvious: it says that the answer is false unless the string is exactly
> "yes", and uncovering the functional equivalence requires resolving a
> double-negative.
Exactly.
>> if(something){
>> return something;
>> }
>> else if(something else){
>> return something else;
>> }
>> else{
>> return some other value
>> }
>>
>> It is much easier to understand and debug
>> the following
First of all, that code above is in a method which returns a boolean.
So there are just two outcomes which can be easily handled by the return
statement with ||. If there are more input values which yield true then
one would rather use HashSet<String> to calculate the return value. At
least that would be the OO solution to me - and not a cascade of, say 7,
if else.
> Style wars much? To me, personally, early-return is often valuable,
> especially in languages like C++ or Java which have useful constructs
> for handling post-call cleanup such as RAII or try-finally blocks. I'm
> going to stop short of saying I prefer early-return, since it is very
> much a decision that applies in a specific context, and these examples
> are all trying to apply a universally generic rule.
Same here.
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <"nospam at neversurrender dot co dot uk"> |
|---|---|
| Date | 2013-06-18 09:03 +0100 |
| Message-ID | <UJ-dnV3mTp3YiV3MnZ2dnUVZ7r2dnZ2d@bt.com> |
| In reply to | #24445 |
On 17/06/13 23:36, Joshua Cranmer 🐧 wrote: > On 6/17/2013 8:46 AM, lipska the kat wrote: >> ... and what is your opinion of defensive coding? > > The term, as I understand it, refers to coding under the assumption that > everyone who uses your API is a stupid idiot who can't follow your rules > properly. Let me say first of all that this has been another very funny exchange. It really is quite amazing how often you guys get all pompous and self-righteous about issues that have nothing whatsoever to do with the issue at hand. Seriously ROFL LOL. Let me try again, I'll try to keep it simple as you are obviously struggling. When you write software to control a device that will be used to interact with human beings you need to anticipate every possible cock up in expected input. You need to deal with erroneous key sequences, incorrect data, communications problems, canceled transactions and any number of other unexpected occurrences and you need to do this in a way that allows you to recover the device and place it in a state that doesn't cause the entire edifice to lock up and crash. *This* is what I mean by defensive programming. It has nothing to do with other people using my API although I expect that if you and you pals were going to be using it I'd have to make it bullet proof. Seriously, read the message properly before going off half cocked. lipska -- Lipska the Kat©: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun
[toc] | [prev] | [next] | [standalone]
| From | Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> |
|---|---|
| Date | 2013-06-18 13:07 -0500 |
| Message-ID | <kpq7bl$of7$1@dont-email.me> |
| In reply to | #24449 |
On 6/18/2013 3:03 AM, lipska the kat wrote: > On 17/06/13 23:36, Joshua Cranmer 🐧 wrote: >> On 6/17/2013 8:46 AM, lipska the kat wrote: >>> ... and what is your opinion of defensive coding? >> >> The term, as I understand it, refers to coding under the assumption that >> everyone who uses your API is a stupid idiot who can't follow your rules >> properly. > > Let me say first of all that this has been another very funny exchange. > It really is quite amazing how often you guys get all pompous and > self-righteous about issues that have nothing whatsoever to do with the > issue at hand. Seriously ROFL LOL. At the risk of being called pompous, I wish to point out that you yourself are not innocent of those charges, choosing the least germane part of my message as the only part to discuss. I'll assume you're doing the same thing I tend to do--only responding to the parts of the message you disagree with. > Let me try again, I'll try to keep it simple as you are obviously > struggling. Oh, I am not so incompetent in reading comprehension as to not know what you meant by defensive programming. I was just pointing out that it wasn't the definition I have heard used before by giving the definition that I used. > When you write software to control a device that will be used to > interact with human beings you need to anticipate every possible cock up > in expected input. You need to deal with erroneous key sequences, > incorrect data, communications problems, canceled transactions and any > number of other unexpected occurrences and you need to do this in a way > that allows you to recover the device and place it in a state that > doesn't cause the entire edifice to lock up and crash. > > *This* is what I mean by defensive programming. And I'd call it "basic principles of good programming." :-) -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2013-06-18 14:48 -0700 |
| Message-ID | <fc74bd14-d684-409b-9bf0-80a2a7e9d8d5@googlegroups.com> |
| In reply to | #24449 |
lipska the kat wrote: > Let me say first of all that this has been another very funny exchange. > It really is quite amazing how often you guys get all pompous and > self-righteous about issues that have nothing whatsoever to do with the > issue at hand. Seriously ROFL LOL. Classic psychological projection. > Let me try again, I'll try to keep it simple as you are obviously > struggling. You are obviously trolling. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <"nospam at neversurrender dot co dot uk"> |
|---|---|
| Date | 2013-06-19 08:36 +0100 |
| Message-ID | <FPOdnUiNMKESwlzMnZ2dnUVZ8rkAAAAA@bt.com> |
| In reply to | #24456 |
On 18/06/13 22:48, Lew wrote: > lipska the kat wrote: >> Let me say first of all that this has been another very funny exchange. >> It really is quite amazing how often you guys get all pompous and >> self-righteous about issues that have nothing whatsoever to do with the >> issue at hand. Seriously ROFL LOL. > > Classic psychological projection. Classic Bloch-local psychobabble nonsense. >> Let me try again, I'll try to keep it simple as you are obviously >> struggling. > > You are obviously trolling. You are obviously retarded -- Lipska the Kat©: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-06-18 23:33 -0300 |
| Message-ID | <%L8wt.20476$5w3.6434@newsfe03.iad> |
| In reply to | #24445 |
On 06/17/2013 07:36 PM, Joshua Cranmer 🐧 wrote: > On 6/17/2013 8:46 AM, lipska the kat wrote: >> ... and what is your opinion of defensive coding? > > The term, as I understand it, refers to coding under the assumption that > everyone who uses your API is a stupid idiot who can't follow your rules > properly. The matter at hand here is basically a stylistic concern about > which is mentally easier to follow, which falls under the category of > "everyone has an opinion which is strongly held and won't be changed." [ SNIP ] Like I stated in a different post in this thread, the stupid idiot is often you yourself (you as in impersonal "you"), since you wrote both the calling code and the called code, and six months later you are adapting the called code and can't remember the assumptions you made previously because you had a whitebox view then, and hence you f**k up. Defensive coding actually means that stupid idiots who "can't follow your rules properly" don't mess up the called system. This has been fundamental software engineering since forever. But you're right, that's not the matter at hand, since I assume that you yourself have a healthy appreciation for defensive coding. > > Style wars much? To me, personally, early-return is often valuable, > especially in languages like C++ or Java which have useful constructs > for handling post-call cleanup such as RAII or try-finally blocks. I'm > going to stop short of saying I prefer early-return, since it is very > much a decision that applies in a specific context, and these examples > are all trying to apply a universally generic rule. [ SNIP ] Rule of thumb - if your average coder gets how the method does exits quickly, then your style is fine. These days - basically the last 2 decades after programming became a commodity and most coders have minimal formal background - I'm all for coding to the LCD. Which means very defensive, and frequently not being elegant in favour of being obvious. 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]
| From | lipska the kat <"nospam at neversurrender dot co dot uk"> |
|---|---|
| Date | 2013-06-19 08:34 +0100 |
| Message-ID | <FPOdnUmNMKGPwlzMnZ2dnUVZ8rmdnZ2d@bt.com> |
| In reply to | #24462 |
On 19/06/13 03:33, Arved Sandstrom wrote: > On 06/17/2013 07:36 PM, Joshua Cranmer 🐧 wrote: >> On 6/17/2013 8:46 AM, lipska the kat wrote: >>> ... and what is your opinion of defensive coding? >> >> The term, as I understand it, refers to coding under the assumption that >> everyone who uses your API is a stupid idiot who can't follow your rules >> properly. The matter at hand here is basically a stylistic concern about >> which is mentally easier to follow, which falls under the category of >> "everyone has an opinion which is strongly held and won't be changed." > [ SNIP ] > > Like I stated in a different post in this thread, the stupid idiot is > often you yourself (you as in impersonal "you"), since you wrote both > the calling code and the called code, and six months later you are > adapting the called code and can't remember the assumptions you made > previously because you had a whitebox view then, and hence you f**k up. [snip] > Rule of thumb - if your average coder gets how the method does exits > quickly, then your style is fine. These days - basically the last 2 > decades after programming became a commodity and most coders have > minimal formal background - I'm all for coding to the LCD. Which means > very defensive, and frequently not being elegant in favour of being > obvious. Elegantly put lipska -- Lipska the Kat©: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web