About java program.

A

Arne Vajhøj

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
 
J

Jeff Higgins

A logical mind, not a programming mind: Psychology of a professional
end-user <http://www.ppig.org/papers/22nd-EUP-1.pdf>

"For his part, J. accepted his responsibility in part as an educational
one, providing C. with valuable skills that would enable her to be more
effective when carrying out future programming work. Given that the two
had comparable professional seniority, this educational objective often
amounted to a clash of alternative intellectual styles. In the
educational approach taken by J., the future development needs described
by C. could be achieved more effectively by adopting more abstract
analysis and problem-solving strategies – strategies that are completely
characteristic of programming work. However, as described in the
Attention Investment model (Blackwell 2002), abstract strategies can be
expensive ones, requiring greater initial investment of attention, with
potentially low return, or even negative return. When pursuing the
educational objectives in his collaborative relationship with C., J. was
therefore acting as an advocate of a more abstract strategy, attempting
to persuade her that she should adjust the attention investment decision
factors that she already applied. In many of their conversations, C.
resisted this advice, saying that she would prefer to make progress on
the specific, concrete, problem that had motivated the project in the
first place. For his part, J. tried to persuade her that it would be in
her long-term interest to address not just this particular problem, but
the general category of problems of this type, or indeed the general
capabilities to be acquired by gaining experience of the most general
capabilities of the programming language. "
 
E

Eric Sosman

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?)
 
L

Lew

Jeff said:
Google-fu failure:
list of very successful software developed by non-professional programmers

On the flip side, there is quite the long list of unsuccessful software
developed by very professional professional programmers.

I've read estimates ranging from 1/3rd to 2/3rd, with many clustering near
one-half, of the failure rate of software projects with costs exceeding
$100 million.

I knew a guy who worked on one of the ones cited in the literature. I've
seen one or two first hand that should have been cited.

There are many definitions of "success" in the software industry, relevant
to a given player defining the term, that differ from the common understanding.
The estimates I have read, however, use a definition along the lines of
"put into production for the avowed purpose of the project".

Even lame systems were counted as successful if they actually went into
production for the avowed purpose.

The programmers in many if not all of these notable failures were, from
what I can determine, not individually incompetent. The problems were either
in the process or emergent from misaligned definitions of "success".

Many contractors define "success" only insofar as they generate billables.
The actual success of the project is implicitly or explicitly secondary.

Trained professional programmers are necessary to successful systems, but not
sufficient.

Even properly constituted projects (one where all stakeholders agree on the
criteria for success and have the requisite skills) risk failure.

I'm not 100% sure what you think, Jeff, based on these links and posts, butI
am 100% sure that you made me think by posting them.
 
J

Jeff Higgins

On the flip side, there is quite the long list of unsuccessful software
developed by very professional professional programmers.

Almost unsurprisingly the unsuccessful case turned more success. I still
haven't found a satisfactory query for either case.
I've read estimates ranging from 1/3rd to 2/3rd, with many clustering near
one-half, of the failure rate of software projects with costs exceeding
$100 million.

I knew a guy who worked on one of the ones cited in the literature. I've
seen one or two first hand that should have been cited.

There are many definitions of "success" in the software industry, relevant
to a given player defining the term, that differ from the common understanding.
The estimates I have read, however, use a definition along the lines of
"put into production for the avowed purpose of the project".

Even lame systems were counted as successful if they actually went into
production for the avowed purpose.

The programmers in many if not all of these notable failures were, from
what I can determine, not individually incompetent. The problems were either
in the process or emergent from misaligned definitions of "success".

Many contractors define "success" only insofar as they generate billables.
The actual success of the project is implicitly or explicitly secondary.

Trained professional programmers are necessary to successful systems, but not
sufficient.

Even properly constituted projects (one where all stakeholders agree on the
criteria for success and have the requisite skills) risk failure.

I'm not 100% sure what you think, Jeff, based on these links and posts, but I
am 100% sure that you made me think by posting them.

A random recreational browsing session unrelated to the post to which I
first
followed up. But reading around the links I posted reminded me of the thread
of discussion. The remaining followups to my followups just mark another
continuation.

What I think. Big World. Small World.
 
J

Jeff Higgins

E.g., another very recent posting to this group took me to
<http://graphexploration.cond.org/> which led to
<http://www.icse-conferences.org/> another incredible little
circularity.

and

From Computing Curricula 2005 The Overview Report
4.5.5. Computing Accreditation in the United States Until recently,
computing accreditation in the U.S. was limited and fragmented. It is
now more unified and more extensive. Historically, two organizations
accredited computing degree programs. The Accreditation Board for
Engineering and Technology (commonly know as ABET) accredited
undergraduate engineering programs of all kinds, including electrical
engineering and computer engineering. The Computing Sciences
Accreditation Board (known as CSAB) accredited undergraduate computer
science programs. Recently, CSAB, recreated as CSAB Inc., has become a
member society of a renamed ABET Inc., and now ABET accredits
engineering, technology, computing, and applied science programs.
Currently, accreditation of CE, CS, IS, and SE programs is ongoing, and
accreditation of IT programs has begun.

?

National Institute for Automotive Service Excellence (ASE)
<http://www.ase.com/About-ASE/ASE-at-a-Glance.aspx>
Sensory Overload: How the New Mercedes S-class Sees All
<http://blog.caranddriver.com/sensory-overload-how-the-new-mercedes-s-class-sees-all/>
 
R

Robert Klemme

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
 
E

Eric Sosman

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

Robert Klemme

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
 
B

blmblm

[ snip ]
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.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,009
Latest member
GidgetGamb

Latest Threads

Top