Jump to content
  • Advertisement
Sign in to follow this  
Diran

Angelscript error handling

This topic is 2457 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!