[asherkin]

ThrowError and ThrowNativeError are for very different purposes, it doesn't make sense to muddle them together.

I your example, I think your goal of doing as little as possible in the native handler is the problem - that's where public API validation belongs (and you have some there, but all 3 TNE checks from CreateModule should be there). Once it gets into your service layer, you should be able to assume that the inputs are correct (as it's internal API, where checking is just pointless overhead).

[rhelgeby]

That would work too, but I don't agree with this approach.

The native layer can't (or shouldn't) know when input is invalid. However, it can of course know that something may go wrong, just not how to verify it itself. That would expose internals of the domain layer, which should be isolated. It also makes it difficult to keep the code in one place (some in natives, some in services and the rest in the domain).

The domain layer should (in my opinion) never accept invalid data, and should throw an error if so. This way I can make sure that my domain objects are always valid, even if there's a bug somewhere that would otherwise insert invalid data. In short, I don't trust the layer above me.

I can solve this myself by using a global boolean variable that I set when entering a native call and reset when leaving (or on an error). I would need to use wrappers for throwing errors, so this solution is dirty and not optimal.

[Powerlord]

Originally Posted by rhelgeby I can solve this myself by using a global boolean variable that I set when entering a native call and reset when leaving (or on an error). I would need to use wrappers for throwing errors, so this solution is dirty and not optimal.

Or you could add an optional argument that, if set to true, means it's being called from a native.

[Greyscale]

Why do you need to validate your internal methods? I think that's the root cause of your issue here. If you just move all validation to the outer API then problem solved. If you want to do internal validation then, conceptually speaking, it's a different type of validation that you'll need to duplicate if you feel you need it. Otherwise your stuck with hacky solutions like the one you proposed.

[rhelgeby]

It's about creating robust isolated code, and to protect myself from making mistakes. Think like exceptions bubbling up the layers.

The only thing I'm missing is something to throw an error in the appropriate place.

[friagram]

There is no point to throw an error in your own api. You know how it works, and it works under strict set of assumptions. If a user passes something stupid to it, then it's expected something will go wrong.

If you want it to be foolproof, you need to either do what powerlord said, and make an arg to skip validation because its internal, or just always validate anyway.

[rhelgeby]

Yes, foolproof. That's the word I've been looking for. I'm trying to stick to a strong principle about creating robust code. And certainly not making assumptions. Even though I know how my code works, I will still make silly mistakes that will propagate through the code if I don't stop it early. This will help me while debugging.

The funny thing is that it's a tiny technical limitation in SourceMod that prevents me from doing it this way.

That's ok. I have another idea. I can use error codes in return values (or an error output parameter). I guess I've been trying code like SourcePawn have exceptiosn, but it doesn't. Error codes will work too.

Thanks for the feedback so far.