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 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.

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.

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.