Closed GoogleCodeExporter closed 9 years ago
just for clarity, here's a patch that implements this.
Original comment by sysbliss
on 6 Sep 2012 at 11:50
Attachments:
any progress on this?
Original comment by sysbliss
on 25 Sep 2012 at 11:37
Original comment by limpbizkit
on 4 Feb 2013 at 4:07
dealing with Throwables still fails in gson-2.2.4. Is the patch ready to be
used ?
Original comment by liviu.ca...@gmail.com
on 13 Jul 2013 at 4:34
I need that patch, too. I'm currently writing a client / server architecture
and the exceptions should also be returned to the client.
Original comment by noctur...@googlemail.com
on 14 Apr 2014 at 10:11
We will not integrate that patch since it has a huge security hole. We can't
trust the class information present in the JSON. We will have to think of an
alternate way.
Original comment by inder123
on 17 Apr 2014 at 10:15
It is ridiculous that GSON still does not support to serialize
Throwable/Exception objects 2 years after it has been reported. This cannot be
too hard to implement.
Anyway, thanks for your great work. But I would be much more thankful if you
would solve this problem ;P
Original comment by simonspr...@gmail.com
on 20 Aug 2014 at 6:38
simonsprankel: I have had some false starts on this, but punted when realized
that the specs aren't clear. Can you explain what your expectations are by
serializing/deserializing an exception object? Please provide some examples as
well.
Original comment by inder123
on 20 Aug 2014 at 6:42
Thanks for your superfast reply! Just FYI, there is also a Stack Overflow
thread on this topic:
https://stackoverflow.com/questions/8151082/gson-an-java-throwable
In the Stack Overflow thread, there is also an example how Jackson serializes
exceptions (though I am not sure if it is still up to date).
I personally would expect that the important fields are properly
serialized/unserialized (so that the getter functions return the same data
after the serialization process):
- cause
- detailMessage
- stacktrace
- suppressedExceptions
But in any case, serializing/deserializing something or just the real basic
stuff would be better than an exception.
Original comment by simonspr...@gmail.com
on 20 Aug 2014 at 6:53
The big problem is the cause field. That is what causes the
CircularReferenceException. I can't figure out a good way to solve it when it
is not null. It requires the general solution for CircularReferenceException
which we have punted on for too long. We used to support it in Gson 1.x....
Original comment by inder123
on 20 Aug 2014 at 7:25
As already written, just skipping the cause field would be better than getting
an exception. It is not too bad if it will be properly documented.
But another idea: Would it be possible to just break the recursion? If we want
to serialize a Throwable "e", which has a Throwable "e2" in its cause field,
can we just ignore the cause field of e2? This should solve the problem, right?
Original comment by simonspr...@gmail.com
on 20 Aug 2014 at 7:32
This issue was closed by revision r1308.
Original comment by inder123
on 16 Nov 2014 at 10:25
Thanks inder123!
Do you know when this is scheduled for release?
Original comment by ant...@gmail.com
on 18 Nov 2014 at 11:13
antweb: Hopefully, this week itself. Just waiting for some code reviews to
complete.
Original comment by inder123
on 19 Nov 2014 at 7:16
Thanks - please let me know when this has been released as my project is
waiting :)
Original comment by ant...@gmail.com
on 10 Dec 2014 at 2:53
@antweb: This is already publicly available with Gson 2.3.1
Original comment by inder123
on 16 Dec 2014 at 7:19
Original issue reported on code.google.com by
in...@trymph.com
on 6 Sep 2012 at 10:58