Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.42!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!74.125.46.80.MISMATCH!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
From: Lew <lewbloch@gmail.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: Avoid creating a stacktrace prior to JDK 1.7
Date: Sat, 1 Oct 2011 20:06:23 -0700 (PDT)
Organization: http://groups.google.com
Lines: 27
Message-ID: <16954967.979.1317524784002.JavaMail.geo-discussion-forums@prng5>
References: <j64ht6$o64$1@news.albasani.net> <j66puk$h0j$1@dont-email.me> <j66t6a$9ta$1@news.albasani.net> <4424828.699.1317485416810.JavaMail.geo-discussion-forums@prng5> <j67kk4$qf3$1@news.albasani.net> <1058576.2212.1317496868028.JavaMail.geo-discussion-forums@prfh23> <j67rp6$afo$1@news.albasani.net> <j67svg$7om$1@dont-email.me> <j682df$9ve$1@dont-email.me>
Reply-To: comp.lang.java.programmer@googlegroups.com
NNTP-Posting-Host: 216.239.45.130
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1317524784 31981 127.0.0.1 (2 Oct 2011 03:06:24 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Sun, 2 Oct 2011 03:06:24 +0000 (UTC)
In-Reply-To: <j682df$9ve$1@dont-email.me>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=216.239.45.130; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T
User-Agent: G2/1.0
X-Google-Web-Client: true
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8475

Stanimir Stamenkov wrote:
> You may be right, but I've read in the Javadoc for=20
> java.util.logging.Logger, for example=20
> <http://download.oracle.com/javase/6/docs/api/java/util/logging/Logger.ht=
ml>:
>=20
> | For the methods that do not take an explicit source name and
> | method name, the Logging framework will make a "best effort" to
> | determine which class and method called into the logging method.
> | However, it is important to realize that this automatically
> | inferred information may only be approximate (or may even be
> | quite wrong!). Virtual machines are allowed to do extensive
> | optimizations when JITing and may entirely remove stack frames,
> | making it impossible to reliably locate the calling class and
> | method.
>=20
> So it seems stack trace information is not guaranteed to be=20
> available to user code.  This detail may be given somewhere in the=20
> language or VM specifications.

Stack trace information is available; the difficulty to which the documenta=
tion 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 a=
vailable.  Just not necessarily useful in the way you'd like.

--=20
Lew