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


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

Re: Avoid creating a stacktrace prior to JDK 1.7

From Lew <lewbloch@gmail.com>
Newsgroups comp.lang.java.programmer
Subject Re: Avoid creating a stacktrace prior to JDK 1.7
Date 2011-10-02 08:37 -0700
Organization http://groups.google.com
Message-ID <32945439.611.1317569831219.JavaMail.geo-discussion-forums@prni6> (permalink)
References (6 earlier) <j67rp6$afo$1@news.albasani.net> <j67svg$7om$1@dont-email.me> <j682df$9ve$1@dont-email.me> <16954967.979.1317524784002.JavaMail.geo-discussion-forums@prng5> <j69dh0$qht$1@dont-email.me>

Show all headers | View raw


Stanimir Stamenkov wrote:
> /Lew/:
>> Stanimir Stamenkov wrote:
>>
>>> You may be right, but I've read in the Javadoc for
>>> java.util.logging.Logger, for example
>>> <http://download.oracle.com/javase/6/docs/api/java/util/logging/Logger.html>:
>>> [...]
>>> So it seems stack trace information is not guaranteed to be
>>> available to user code.  This detail may be given somewhere in the
>>> language or VM specifications.
>>
>> Stack trace information is available; the difficulty to which the
>> documentation alludes is that the stack might be in an odd state,
>> not that it wouldn't be available.  So it seems stack trace
>> information is guaranteed to be available.  Just not necessarily
>> useful in the way you'd like.
>
> So while Throwable.getStackTrace() might not be null it could be 
> empty which effectively means no stack trace information available 
> <http://download.oracle.com/javase/6/docs/api/java/lang/Throwable.html#getStackTrace%28%29>:
> 
> | Some virtual machines may, under some circumstances, omit one or
> | more stack frames from the stack trace. In the extreme case, a
> | virtual machine that has no stack trace information concerning
> | this throwable is permitted to return a zero-length array from
> | this method.

Right, but in those "extreme" cases you have a situation where no stack trace information is available to be made available, if you get my drift.  And they don't help the OP, because he's trying to suppress stack trace information when it could be made available, and he can't count on there being no stack trace available to be available.

My point was that it isn't quite accurate to say that stack trace information isn't available to user code - in the even that there is any stack trace information, that is.  If there isn't, the Throwable at least reports that there is nothing to report, which gives the programmer more information than would a failure to report.

So it seems stack trace information is guaranteed to be available.  Just not necessarily useful in the way you'd like.  But still useful to some degree, more than not making available whatever paucity of information there is.

There's a difference between "no information" and "information that there is no information".  The latter tells you something, at least.

-- 
Lew

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


Thread

Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-09-30 15:57 +0200
  Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-01 13:27 +0300
    Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-01 13:22 +0200
      Re: Avoid creating a stacktrace prior to JDK 1.7 Lew <lewbloch@gmail.com> - 2011-10-01 09:10 -0700
        Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-01 20:31 +0300
        Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-01 20:02 +0200
          Re: Avoid creating a stacktrace prior to JDK 1.7 Lew <lewbloch@gmail.com> - 2011-10-01 12:21 -0700
            Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-01 22:04 +0200
              Re: Avoid creating a stacktrace prior to JDK 1.7 Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-01 16:24 -0400
                Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-01 23:14 +0200
                Re: Avoid creating a stacktrace prior to JDK 1.7 Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-01 17:28 -0400
                Re: Avoid creating a stacktrace prior to JDK 1.7 Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-10-01 23:45 +0000
                Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-02 00:58 +0300
                Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-02 02:04 +0200
                Re: Avoid creating a stacktrace prior to JDK 1.7 Lew <lewbloch@gmail.com> - 2011-10-01 20:06 -0700
                Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-02 13:14 +0300
                Re: Avoid creating a stacktrace prior to JDK 1.7 Lew <lewbloch@gmail.com> - 2011-10-02 08:37 -0700
                Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-02 20:26 +0200
                Re: Avoid creating a stacktrace prior to JDK 1.7 Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-02 17:51 -0400
                Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-03 01:32 +0200
    Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-01 20:19 +0300
      Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-01 20:04 +0200
        Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-01 21:15 +0300

csiph-web