Hi, Andreas

Is there a particular reason why Angelscript uses return codes instead of exception propagation?
It gives me a lot of headache recently. For example:

asIScriptFunction *setfunc = classType->GetMethodByDecl("void getProperty(int value)");

This one will return a null pointer cause of a typo in a passed declaration param. Ok, let's skip pointer check.

Then a code follows

context->Prepare(setfunc); //returns asNO_FUNCTION
context->SetObject(&scriptClassObj);
context->SetArgObject(0, &arg );
context->SetArgDWord(0, 22);//return asCONTEXT_NOT_PREPARED
context->Execute();
And it's fine here. We had some serious problems inside, but nothing crashed, nothing reported. The code is just
executed without a proper result.


So, either I have to check every pointer for null / return code for good, or to write wrappers for every AS class to handle this in a proper way.
Both ways are crap, require a lot of work and the code gets bloated.

And all I actually need is
catch(ASException& e)
{
//abort/report/whatever
}

Why not?

You assume exception handling is acceptable for all of AS' target platforms when it really isn't.

Portability is one reason, but also the fact that I honestly dislike the use of exception handling. In my opinion it should only be used for, true exceptions, i.e. where things are out of control, and not for normal error handling.

You don't have to check the return code for every call to AngelScript. Just where it matters to you. In the above, you should at the very least check the return code for the Execute() call. Unless it returns asEXECUTION_FINISHED you can be sure something went wrong and you need to investigate what it was.

Well, attempt to execute not existing function is enough out of control for me. If it demands to interrupt a program execution - it is the case for exception to be risen.
The problem with checking Execute() call is that error it produces is not informative. It implies "Go and debug". The information about the actual cause of the problem is lost.
And using in place exception solves the problem and saves time. I am sure you understand the difference between the message in the log
like
NO_SUCH_FUNCTION g

etProperty(int value)

and EXECUTION_FAILED. In the first case it's obvious, and debugging is not required at all.

I thought that portability problem may be the only objective reason. But that's not my area at all. Can you shed some light on this?

The portability issue is quite simple: Not all platforms support exception handling.

In your case this situation may be considered an exception, but you cannot generalize and say that this is always the case. To be true to both ways of thinking I would have to provide duplicate methods, one that throws and another that don't throw exceptions. This is not something that I'm willing to do.

However, what do you think of AngelScript providing more information to the message callback in cases like this? The GetMethodByDecl() call could for example write a message like "No matching method for 'void GetProperty()' in object 'Object'". I can add similar messages in other methods, like Prepare and Execute.

From the point of view of someone writing a wrapper around AngelScript that uses exceptions, it might be more convenient instead of/in addition to writing extended error information to the message callback, store the extended error information in a location that can be queried via a function like SDL's SDL_GetError() function.

Indeed. Perhaps for errors in system functions, that are not compilation related I should provide a GetErrors() function. I'll think about the best way of doing this. Thanks for the suggestion.