Recommended way of decoding non-framed messages?

[tsuna]

On Sun, Aug 1, 2010 at 5:34 PM, brunodecarvalho <kindernade at gmail.com> wrote:
> On Sun, 2010-08-01 at 17:12 -0700, tsuna wrote:
>> Regarding the paragraph you quoted from JLS, do you have any idea as to
>> why
>> > it is "prohibitively expensive" to store the stack trace?
>>
>> Yeah, I understand their point, and it seemed to contradict Netty's
>> javadoc.
>>
>
> Actually, I was kind of expecting you'd shed some light on my understanding
> of this cost. I've tried to find something that backed up that JLS statement
> but I really didn't find anything.

My understanding of it (and I admit they're not crystal clear) is that
they're saying that generating a stack trace is expensive (as your
micro benchmark confirms) and that *unless it is actually thrown* this
would be a huge waste of time / space.  They seem concerned with the
fact that one part of a program could create a Throwable, and then
give it (not throw it) to another part of the program.  If this other
part decides to not throw the Throwable, then the effort done at the
beginning to populate the stack trace is going to be wasted.  They
seem to argue that it's better to wait until the Throwable is actually
thrown to populate the stack trace as the stack is being unwound.
However, clearly, that's not how Sun's implementation behaves (which
is entirely legitimate anyway since the JLS basically says "do
whatever you want with stack traces").

$ cat e.java && javac e.java && java e
final class e {

  static final Throwable t = createThrowable();

  static Throwable createThrowable() {
    return new Throwable("boom");
  }

  static void explode() throws Throwable {
    System.out.println("explode");
    throw t;
  }

  public static void main(String[] a) throws Throwable {
    t.printStackTrace();
    explode();
  }

}
java.lang.Throwable: boom
	at e.createThrowable(e.java:6)
	at e.<clinit>(e.java:3)
explode
Exception in thread "main" java.lang.Throwable: boom
	at e.createThrowable(e.java:6)
	at e.<clinit>(e.java:3)

It's pretty obvious that the stack trace was populated right when `t'
was created, not when printStackTrace was called or when it was
thrown.  Could it be that the JVM is able to statically determine that
this has a non-zero chance of being thrown?  I don't know.



Anyways, Netty's javadoc is misleading.  ReplayingDecoder isn't cheap
because it's throwing an Error, it's cheap because it keeps re-using
the same Throwable (regardless of whether it's an Error or an
Exception).  This is just a detail, of course, but it caught my
attention :)

-- 
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com