If you have a custom command and an exception is thrown within your code, good programming practice is to handle that exception and not let it bubble up to the hosting application. The reason is that the hosting application may not know how to handle the exception properly. Some API's may have built in support for passing specific types of exceptions up the stack, but Vault Explorer does not have one of those APIs.
Let me explain what happens when you throw an exception from a custom command within Vault Explorer. If the exception is directly on Vault Explorer's call stack, it will get "eaten" by Vault Explorer. In other words, Vault Explorer will catch the exception then do nothing with it. This is the intended behavior for Vault Explorer. However I have recently become aware of a few cases that result in un-intended behavior.
One interesting back door is when the exception comes from an event in custom UI. For example, your command launches a custom dialog, and your OnClick event code has an exception that you don't handle. In this case, the Vault Explorer treats it like an exception from any of the built-in dialogs and attempts to handle the issue. Usually the handling involves parsing the error and displaying a formatted error dialog.
In the case of server errors (SOAPExceptions), this is great because Vault Explorer will parse the error for you and display it in the proper language.
I'll admit, this is pretty nice back door. The only downside that I can see is that the error text was written with Vault Explorer in mind and may not make sense in the context of your application.
But if the exception is not a SOAP Exception you will likely get a CER dialog. If you don't know what a CER dialog is, let me show you a picture.
Recognize it now? You want to avoid this dialog.
An even worse case comes up if your command spawns a thread which bubbles up an exception. In that case, the CER pops up and the application crashes.
You really want to avoid this dialog.
The best way to avoid these bad cases is to handle your exceptions. When in doubt, you can always wrap everything in a try/catch block. See examples below.
// an event in a custom dialog
// the start function on a thread
' the Execute method for a custom command
' an event in a custom dialog
' the start function on a thread