Hi Paolo, It is an interesting point! It seems like a good idea not to throw exceptions from methods invoked by native code.
You can still throw exceptions before and after invoking native code (outside of call-backs) so the problem doesn't affect the recommendation I made that public methods in GTK# should throw exceptions rather than use error codes ;-). All the best, ^Tum > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:mono-list- > [EMAIL PROTECTED] On Behalf Of Paolo Molaro > Sent: Wednesday, 26 March 2003 12:30 a.m. > To: [EMAIL PROTECTED] > Subject: Re: [Mono-list] Exceptions and error codes. > > On 03/21/03 Thong (Tum) Nguyen wrote: > > > You make some good arguments, but I think most of it is irrelevant > > > since, in order to remain compatible with .NET, Mono must behave the > > > same way with respect to returning (or not) exceptions. The MSDN docs > > > describe exactly what exceptions/return codes File.Exists and > > File.Open > > > should return, Mono should do the same (unless the docs are in error). > > A > > > lot of work has already been done on this. You'll notice that many of > > > the test cases test whether or not the correct exception is being > > > returned. > > > > > > Definitely. I was more referring to our own class libraries (such as > > GTK#). > > I just want to add another data point to the ones already explained > about the use of error codes or exceptions, especially as it relates to > Gtk+, but this also applies to other libraries that are P/invoked from > the CLR. > C code has no notions of exceptions and of the way exception handling > can unwind the stack (yes, on windows people use SEH in C code, but it's > non-standard and I don't even know if the MS CLR deals with SEH in C > code). So what may happen is: > > C# code with a try block > -> Gtk+ code (takes a lock and calls a delegate) > -> C# code that trows an exception > -> exceptions handling triggers and gets the stack back to the try > block > -> next time Gtk+ is called again and it needs the lock (that > could be not unlocked by the exception code, since it's not > aware of it) you get a nice deadlock > > lupus > > -- > ----------------------------------------------------------------- > [EMAIL PROTECTED] debian/rules > [EMAIL PROTECTED] Monkeys do it better > _______________________________________________ > Mono-list maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/mono-list > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.461 / Virus Database: 260 - Release Date: 10/03/2003 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.461 / Virus Database: 260 - Release Date: 10/03/2003 _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
