When i am going through this url article published in july 2010
http://fog-framework.blogspot.com/2010/07/type-safe-scripting-engines-for-c.html

it is listing the disadvantage of angelscript regarding exception as
"[color=#333333][font=Georgia, serif][size=2]Only text exceptions, no try-catch blocks in the code. Exception is something that shouldn't happen and it's handled by the your C/C++ code."[/font]
[color=#333333][font=Georgia, serif][size=2]
[/font]
[color=#333333][font=Georgia, serif][size=2]is it really "still" so, or it has been added[/font]
[color=#333333][font=Georgia, serif][size=2] [/font]
[color=#333333][font=Georgia, serif][size=2]( I am asking this , because one disadvantage of angelscript listed here, [/font]
[color=#333333][font=Georgia, serif][size=2] "[/font][color=#333333][font=Georgia, serif][size=2]No inheritance for C/C++ classes. This makes the scripting engine totally unuseful for GUI ". [/font]
[color=#333333][font=Georgia, serif][size=2] This disadvantage is removed, i know. So i am hoping that whether the above thing (which i have asked about) has also been done[/font]
[color=#333333][font=Georgia, serif][size=2])[/font]
[color=#333333][font=Georgia, serif][size=2]hence, to restate the question: "whether try catch i can do in angelscript or not"?[/font]

you know you could give yourself a hernia making threads this fast?

You can, on the C++ side, set exceptions in the asIScriptContext and it will halt execution for you.

I haven't implemented support for 'try/catch' blocks in the script language yet. It is still on my to-do list.

Any particular reason why you want this?

I have lots of utility libraries which have full OO implementation (that is no C like error code, only exceptions of C++).
These libraries exposed into angelscript should feel same to my end user , now he should not be dealing with error codes in angelscript,
He should be able to extend these exceptions wih his own. So it will be good (for uniformity and no-confusion sake) that C++ and angelscript model of object heirarchy should be exactly same (in the object oriented sense) and the way of dealing it too should be the same.

Second, i would like to ban the user from using normal int etc types, i want that all the types should be classes. So i will expose an Integer class for the same.
though this will not give me -2.abs or -2.abs() like in groovy
Integer i = new Integer(-2); (this may not be a strictly angelscript syntax, i am just trying to roughly express)
i.abs()

Hence, implementation of OPTIONAL TRY-CATCH exceptions and AUTOBOXING (int to Integer class and vice versa) will help me in making my scripting language almost fully object oriented/ even if not purely object oriented. Which is a must for me, due to almost all my client people's sole insistence on pure object orientedness as a policy. Though i am dying something like scala (which nicely integrates primitive types and object oriented types); but i will happily be contented with OPTIONAL TRY-CATCH exceptions and AUTOBOXING . Thats why i was evaluating angelscript with these concerns.

One request: Whenever you implement it, like in groovy, do not make it mandatory to catch the exceptions or rethrow it. It must be "optional"
http://mrhaki.blogspot.com/2009/09/groovy-goodness-exception-handling.html

I haven't implemented support for 'try/catch' blocks in the script language yet. It is still on my to-do list.

Any particular reason why you want this?

@ _orm_ :
i am sorry if i asked many questions in a single day and that was inconvenient to you or anybody else.

Actually, when i saw angelscript and nullc languages, i became enthusiastic, and i tried to decide on one of them into my application. As there were four-five different features essential for me in a scripting language, hence i tried to satisfy my urgency aggravated by my excitement for angelscript and nullc.
I am sorry for that.


But, you could have reminded/warned me about this at first, and if not followed by me even in next many days, then you could have said anything about me. But in the first instance you started personal comments on me, which is very sad.

community around a language has to be built by general helping attitude (and that may be combined with humble discpilinary posts like "plz read the FAQ that you should not do this /that"). But if people get personal on the very first day on slightest anooyances, then it will be hard for the curious guests and they will go away , WHO COULD HAVE BEEN future contributing users/part of the community.
Have you seen stackoverflow.com and how people are mostly contributing on the topic and "how good it is moderated with removed posts/replies with stated that - this post has been removed/edited due to this/that" . This serves well as a reminder for that user that he needs to change any bug in his action. But nowhere personal attack is tolerated there. "You post also could have been a candidate for removal by moderator."

I hope that my point is well understood.

Again, i am sorry if i had ruffled anybody or _orm_ by this post or past posts.

I'm not a big fan of exception handling. They are good for exceptions (pun intended), but treating normal error handling, i.e. the expected errors, with exceptions and try/catch blocks is not good in my opinion. I've seen so much code where the exception handlers' catch blocks take up many times more lines of code than the actual logic, and all because there are multiple different exceptions that has to be handled in the same way.

But I digress. My opinion doesn't really matter. I will eventually implement try/catch blocks as they do have usefulness in some cases. And when I do implement it, they will be optional, you will definitely not be forced to catch exceptions you do not want to handle.


Why on earth do you want the script to mirror the application code in all aspects? What is the usefulness of the scripts in this case? Who is your target audience for the scripts? The expert programmer or the novice developer? I'm not saying that your doing anything wrong, I just cannot understand why you want to go through so much trouble to have the script as similar to the application code as possible. Scripting is usually meant to simplify things, which includes having a much simpler programming interface.

Thanks for positive roadmap
My target users are developers themselves, to whom their higher technical management do not trust to let delve into the C++ pointer mismanagement, but rather a safe sandbox of small scripting language but still powerful object oriented enough.
you can think it like this, many C++ API (or C API) are consumed by me, as i am a a good C++ (third generation language) developer;
- but i am "not" apt at assembly language (1 layer lower),
- i am also "not" good at database administrator role like "SQL (declarattive and fourth generation language) optimization" (1 layer higher).
I am good at my own layer C++

in the same way , their project manager do not want to allow intern level /fresher/his lower level programmers the pointer mismanagement risk of C++, but still he trusts their object oriented instincts, as many of them are good ruby programers (due to Ruby on Rails hype). He also does not want ruby,python due to their non-C syntax and their large size overhead for their application.

So angelscript / nullC (code.google.com/p/nullc/ ) / jewelscript ( http://blog.jewe.org/?p=19 ) will mean:
no pointer mismanagement (for goodness of their fresher programmers coming from ruby and PHP side)
still as much object orientation as possible (for goodness for their tech lead)
C syntax
safe sandbox

Hence, here arises a "purely object oriented but still safer" need for [color=#1C2837][size=2]the script to mirror the application code in (almost) all aspects.

and this (object oriented) mirroring is of the API only(which is still a large API) , not the classes behind the API.

@ _orm_ :
i am sorry if i asked many questions in a single day and that was inconvenient to you or anybody else.

I'm sure _orm_ was just joking. Feel free to post as much as you like.

I'm especially interested in feature requests like the ones you're suggesting. This is what allows me to determine the future direction of the library.

Do let me know which library you choose in the end, and if possible the reasons behind the choice.

i am also going to consider dart language ( www.dartlang.org ) by GOOGLE
considering that it will also be executable in a VM too (apart from javascript mode)
not much details are out yet.

main worry is what is the size of their VM? that i will have to look out.