The more I am thinking about a new exception/error model being proposed for SteelKix, the more I oppose to it. At this point, it is possible for builtin SteelKix functions to swallow .NET exceptions and use the plain old kix error code model. At runtime, the SteelKix runtime swallows COM exceptions and sets the proper error codes. With these two points in mind, the whole vanilla kix error code model can be implemented for the current kix functionality without having to cripple the new functionality of steelkix that involves the use of .NET (libraries).

There are a lot of new things in SteelKix, but most of those things are in place to make interop with .NET a lot easier, including exception handling. The whole point of SteelKix is the use of .NET libraries while keeping most of the simplicity of kix in place. Most of the features are actually additions to kix, not substitutions. The only problem now is that the exception models are not compatible, so the initial choice was a more or less 'hybrid' model, where all of the vanilla kix functionality operates in the 'error code' model and the new .NET features operate in the exception model.