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

Groups > comp.lang.java.programmer > #12864

Re: Exception Handling

Show all headers | View raw

Arved Sandstrom wrote:
> Lew wrote:
> [ SNIP ]
> We may be talking/thinking at cross-purposes here: you, me, the article
> author, and Novice. The logging article author states that you should
> never include file name, class name, or line number. To be accurate the
> article is an edited compilation of what another fellow (Tomasz
> Nurkiewicz) has written about logging: I haven't been able to find the
> originals to see what Tomasz put forth as explanation for this stance.
>
> Further, and presumably this also comes from Tomasz, it's stated that
> "logging class name, method name and/or line number has a serious
> performance impact." Now, to be fair to him this is also still
> promulgated by Ceki Gulcu's log4j documentation.
>
> I suspect that in recent years with newer JVMs that the performance
> impact of some of the position conversion specifiers is considerably
> less than it was when the warnings were first issued.
>
> Having said that, *my* argument against regularly using source position
> information is motivated by retaining clarity of logs. Try reading logs
> in a text editor or on the console when the first part of every entry is
> not only level and timestamp and thread ID but also FQ classname,
> methodname, and line number. That positional info is irrelevant almost
> all the time, and yet a _default_ decision to include it seriously
> clutters logs. The info you really want starts halfway across the editor
> window. The human eye is also not that great at differentiating one blob
> of letters from another; ignoring the level and timestamp is easy (they
> "look" different when scanning), but the positional info easily runs
> together with the real message.
>
> My position is, if you need it, include it. Don't default (let's say
> through PatternLayout strings) to having it uniformly. Bear in mind (if
> performance is still any kind of concern) that the log4j %c conversion
> specifier gives you classname for free if you're creating loggers by
> class. You don't need it for errors, not if you're dumping stacktraces.
> You surely don't need it for info or warnings. Debug may or may not
> benefit from positional information, but that should be case by case,
> and if you do need a debug statement to include positional info, what's
> so tough about putting it in that one, specific debug message?

I see. Good points.

>> I disagree. You should end the program gracefully and get someone to fix
>> the programming error right away.
>>
> [ SNIP ]
>
> Not often in the real world can you do that, Lew. And you know it. One

At another point in that post, not cited, I talk about not ending the program 
but, "Somewhere up the stack you should catch the exception and convert it to 
valid program state."

You are right that that is often not ending the program. As I also said in 
that post, in answer to when the program should abend, "Never. Program exit 
should be under user control."

So I agree with you.

> source of work like this (fixing errors) for ops support and maintenance
> programmers is operational problem reports (trouble tickets etc)
> detected and entered by business. Another is ops support monitoring
> (Splunk, say) of logs...in which case something they detect may also
> enter the ticket/defect tracking systems.
>
> Unless something is truly critical nobody is going to shut down a 24/7
> public-facing or partner-supporting (b2b) system just because a
> programming error popped up as a runtime exception. In fact, in the
> absence of any problem reports from the field an issue like that might
> well end up as a low/medium severity, low/medium priority defect - mixed
> in with dozens or hundreds of others - that'll get handled a few weeks
> or months later.

As I also stated.

In the cases you state, "exiting gracefully" means "when the operator says 
so". There is nothing in my statements to gainsay your points. /Au contraire/, 
I spoke against exceptions crashing or stopping a program.

And you know it.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Exception Handling Novice <novice@example..com> - 2012-03-11 01:51 +0000
  Re: Exception Handling Lew <noone@lewscanon.com> - 2012-03-10 18:39 -0800
    Re: Exception Handling Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-11 11:53 -0300
      Re: Exception Handling Lew <noone@lewscanon.com> - 2012-03-11 10:51 -0700
        Re: Exception Handling Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-11 16:35 -0300
    Re: Exception Handling Novice <novice@example..com> - 2012-03-11 17:05 +0000
      Re: Exception Handling Lew <noone@lewscanon.com> - 2012-03-11 10:53 -0700
        Re: Exception Handling Novice <novice@example..com> - 2012-03-11 20:36 +0000
      Re: Exception Handling Lew <noone@lewscanon.com> - 2012-03-11 11:07 -0700
        Re: Exception Handling Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-11 17:00 -0300
          Re: Exception Handling Novice <novice@example..com> - 2012-03-11 22:02 +0000
        Re: Exception Handling Arivald <NOSPAMarivald@interia.pl> - 2012-03-11 21:03 +0100
          Re: Exception Handling Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-11 18:31 -0300
        Re: Exception Handling Novice <novice@example..com> - 2012-03-11 21:54 +0000
          Re: Exception Handling Patricia Shanahan <pats@acm.org> - 2012-03-11 15:26 -0700
            Re: Exception Handling Novice <novice@example..com> - 2012-03-11 23:23 +0000
              Re: Exception Handling Lew <noone@lewscanon.com> - 2012-03-11 16:52 -0700
                Re: Exception Handling Novice <novice@example..com> - 2012-03-12 17:16 +0000
                Re: Exception Handling Lew <noone@lewscanon.com> - 2012-03-13 08:31 -0700
              Re: Exception Handling Patricia Shanahan <pats@acm.org> - 2012-03-11 17:51 -0700
                Re: Exception Handling Novice <novice@example..com> - 2012-03-12 17:26 +0000
            Re: Exception Handling Arne Vajhøj <arne@vajhoej.dk> - 2012-03-12 14:49 -0400
          Re: Exception Handling Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-11 20:46 -0300
            Re: Exception Handling Novice <novice@example..com> - 2012-03-12 17:43 +0000
      Re: Exception Handling Patricia Shanahan <pats@acm.org> - 2012-03-11 11:14 -0700
        Re: Exception Handling Novice <novice@example..com> - 2012-03-11 22:35 +0000
          Re: Exception Handling Lew <noone@lewscanon.com> - 2012-03-11 16:58 -0700
            Re: Exception Handling Novice <novice@example..com> - 2012-03-12 15:44 +0000
              Re: Exception Handling Gene Wirchenko <genew@ocis.net> - 2012-03-12 10:34 -0700
      Re: Exception Handling Arivald <NOSPAMarivald@interia.pl> - 2012-03-11 20:34 +0100
        Re: Exception Handling Novice <novice@example..com> - 2012-03-11 22:36 +0000
    Re: Exception Handling Arne Vajhøj <arne@vajhoej.dk> - 2012-03-12 14:41 -0400
  Re: Exception Handling Arne Vajhøj <arne@vajhoej.dk> - 2012-03-12 14:37 -0400
    Re: Exception Handling Novice <novice@example..com> - 2012-03-12 22:43 +0000
      Re: Exception Handling Lew <lewbloch@gmail.com> - 2012-03-12 16:11 -0700
      Re: Exception Handling Arivald <NOSPAMarivald@interia.pl> - 2012-03-13 00:54 +0100
        Re: Exception Handling Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-13 06:05 -0300

csiph-web