Would it be possible / realistic to serialize and un-serialize an exception?

# server

[Avi Perl]

Would it be possible / realistic to serialize and un-serialize an exception?

[Endre Deak]

why would you do that?

[Avi Perl]

My purpose is to make an exception that could be thrown in one vertx vertical and caught in another.

[Avi Perl]

Communication between verticals is json.

[Avi Perl]

Somehow, I always need exceptions to be handled by the caller, instead of the request dying somewhere along the line. My thought for a solution was a cross vertical exception class that could be used.

[czuckie]

my personal preference would be to create a contract between the caller and the handler such that if an error occurs, a known response would be sent back such that the caller could understand what had happened.

This known object may have things that appear in exceptions, e.g. the exception message, the cause, even a stack trace perhaps, but that'd be pushing it. I'd rather have something more domain specific to what I was doing rather than something technology specific which could change in the future when I changed the underlying tech from Postgres to MariaDB for example

[Avi Perl]

But programming languages have such a system in place, exception handling!

We do have such a contract as you describe, for success messages. When considering what an error message would look like, you very quickly arrive at what an exception looks like. The way we handle exceptions in an application works quite well, why reinvent it with some sort of abstraction?

[Avi Perl]

Where I think things could fall apart is that exception instances might have quite a bit more inside of it than I truly care about. And serializing those details maybe a great deal of work for nothing. I almost certainly just care for an error code, an error message, and in my case, probably an array of data.