On Tue, Feb 15, 2011 at 10:13:11PM +0100, Mark de Wever wrote: First of all a small update regarding the conclusions I made yesterday.
> So I conclude that code that throws an exception which is caught by Lua > behaves like: > - catch all std::exceptions and `handle' them > - crash on all other exceptions The crash on all other exceptions was caused by deferring a NULL pointer. I fixed that issue [1]. So the current behaviour is: Lua catches all exceptions and shows the message (via the what member function). All exceptions are stopped by Lua. Silene also added a sticky exception to allow some exceptions _without_ payload to be rethrown. That regarding the status of the exceptions. Another question is how to proceed with Lua? It still violates our coding standards. Below the options I see: 1. Remove Lua. 2. Do nothing. 3. Rewrite Lua so it fully complies with our standards. 4. Try to make the best of it. 5. Make Lua external again? Below my personal opinion regarding these options. 1. Lua is used a lot in our code and in UMC as well. So I feel we can't remove Lua unless we want to change a lot of code and make a (huge?) part of the UMC community unhappy. (And unhappy is an understatement.) 2. As lined out in my emails the last days, I consider the current implementation broken so I see this not as an option. 3. I feel this would be the best solution, however I fear nobody will step up to take the job. 4. Let me explain the idea first: In order to get the VALIDATE macro working again like in 1.8, I added a new exception class tlua_jailbreak_exception. When this exception is caught by Lua it copies the exception including its payload. When Lua is finished it throws the exception again. The exception catching happens in the same way std::exception is caught by Lua to store its message. The rethrow happens in the same function as the sticky exceptions Silene implemented. So this code is safe. That way every exception that derives from tlua_jailbreak_exception can be thrown `through' Lua. This means that exception classes we create we can choose whether or not they should go `through' Lua. We create to be rethrown, std::exceptions will still be blocked by Lua. Exceptions that derive from both tlua_jailbreak_exception and std::exception are thrown through Lua. External libraries (read boost) that throw exceptions are thus also caught by Lua, of course it is possible to make an exception for other exceptions in the same way std::exception and tlua_jailbreak_exception do. I still feel this option doesn't comply with our coding standards regarding exceptions, so if choose this option we need to change the coding standards to allow Lua to have an exception regarding exception handling. This change does modify an `external' lua file and thus make it not possible to use an external lua++ library [2]. I don't know whether there will ever be a lua++ library, but I think we shouldn't speculate on it. For those who want to review the change I posted the concept changes [2], note that I reformatted the current code to make it a bit more readable. 5. I haven't checked whether it fixes it, but I expect it will fix it. But it will be a lot of work and Silene said that that implementation is rather error prone. For these two reasons I think we shouldn't do this. (It is also the reason I didn't bother to test whether it really fixes it.) Conclusion: I think we should go with option 4 unless somebody steps forward to implement option 3. Like I said, I have a working prototype for option 4 and I volunteer to implement option 4. Note however I do _not_ volunteer to become the Lua maintainer. Finishing GUI2 will keep me occupied for a while. [1] http://svn.gna.org/viewcvs/wesnoth?view=rev&revision=48532 [2] https://mail.gna.org/public/wesnoth-dev/2010-07/msg00071.html [3] http://wesnoth.pastebin.com/wbTidarZ -- Regards, Mark de Wever aka Mordante/SkeletonCrew _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
