Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > About java program.

Reply
Thread Tools

About java program.

 
 
Robert Klemme
Guest
Posts: n/a
 
      07-06-2013
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/

 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      07-06-2013
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
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      07-06-2013
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

 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      07-06-2013
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

 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      07-06-2013
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
 
Reply With Quote
 
Jeff Higgins
Guest
Posts: n/a
 
      07-07-2013
On 06/19/2013 07:20 PM, Lew wrote:
> Arved Sandstrom wrote:
> . . .
>> If we stick to Java, the LCD doesn't quite get the difference between
>> reference and equals() comparisons, and when informed still needs
>> coaching to write a good equals(). The LCD often has never heard of
>> O(n), and far from being able to choose a good sort has in fact never
>> heard of most of the common sorting algorithms. Same goes for search, I
>> run across coders all the time that have never heard of fundamental
>> search strategies. This average programmer doesn't read blogs or
>> articles, doesn't know white box or black box testing theory, knows
>> almost nothing about JVM tuning [1], and is very weak on concurrency. So
>> forth and so on.

>
> The sad thing is that your observations are accurate, and mine are similar.
>
> The thing that makes me mad is that, despite these people's job titles,
> they are not computer programmers. The things you describe are elementary
> programming knowledge, things taught early in the process. For anyone to
> collect a paycheck for that skill not to know these things is an insult.
>
> They should be fired.
>
> This is the sort of thing that makes me favor making computer programming
> a formal engineering discipline. No one, at all anywhere, should tolerate someone
> calling themselves a computer programmer who is that ignorant, incompetent and
> uncommitted to the skills of their profession, let alone pay them for it.
>


A recent browsing session starting at

Computing - From Wikipedia, the free encyclopedia
<http://en.wikipedia.org/wiki/Computing>

led to

Laplante, Phillip (2007)
What Every Engineer Should Know about Software Engineering
<books.google.com/books?isbn=1420006746>

and

Software Engineering Body of Knowledge
From Wikipedia, the free encyclopedia
<http://en.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge>

and

Curricula Recommendations
Association for Computing Machinery
<http://www.acm.org/education/curricula-recommendations>

 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      07-07-2013
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/
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      07-07-2013
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
(E-Mail Removed)d
 
Reply With Quote
 
Jeff Higgins
Guest
Posts: n/a
 
      07-07-2013
On 07/07/2013 01:31 PM, Jeff Higgins wrote:

> Software Engineering Body of Knowledge
> From Wikipedia, the free encyclopedia
> <http://en.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge>


<http://martinfowler.com/bliki/Swebok.html>
 
Reply With Quote
 
Jeff Higgins
Guest
Posts: n/a
 
      07-07-2013
On 07/07/2013 01:31 PM, Jeff Higgins wrote:

> A recent browsing session starting at


> led to


> and


> and
>

Fabio Patern˛
End User Development: Survey of an Emerging Field for Empowering People
<http://www.hindawi.com/isrn/se/2013/532659/>
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
I need your advices about C prg. Dogukan Bayraktar C Programming 76 06-16-2013 08:54 AM
Survey about Software Integration Martin Dias C Programming 0 04-29-2013 03:23 PM
Quesion about running a exe file in Python(Not enough memory) yuyaxuan0@gmail.com Python 5 04-26-2013 06:30 AM
silly question about Running a script from the command line A.Rock Python 0 04-10-2013 11:21 AM
newbie question about confusing exception handling in urllib cabbar@gmail.com Python 6 04-09-2013 07:11 PM



Advertisments