I have been searching through documentation and forums this morning to try to understand what will happen if a message-driven method (like all the methods in many of our services) throws an exception. So far, I have not found anything useful. I imagine it might work to have a local event-driven endpoint throw an exception, but most likely it won't because the code that gets generated between the caller and callee will not be defined to throw the exception. It's even harder to understand what would happen if the server threw an exception in response to a broker message, unless we are really doing synchronous RPC.
We have defined separate exception types corresponding to most of our message types, but there's no code I can find that catches any of them. This cannot be correct. If all that's going to happen is that they get logged, then we should be writing the log messages ourselves. If the server is going to crash, that's unacceptable of course.
Unless someone can point me to a clear description of how this is supposed to work, I think we'll need to get rid of all these exceptions and go to error logging and in some cases distinguished return values.
OK, I finally found it. This sounds complicated. I think we need to look at each exception type and either get rid ot if, or document exactly why it gets thrown, and how it's going to be caught and handled.
At this point, I have removed most exception types from the common and server-interface modules, and as far as I can find them, from accounting and auctioneer. I also wrote up a wiki page to document the cross-module exception types we WILL use. Please don't throw an exception unless you document it here. Most of the ones that remain are at risk because I don't know how we are supposed to handle them.
If anyone has a brilliant idea for making this simpler, please let me know.