[Mono-list] Exceptions and error codes.
Thong (Tum) Nguyen
Wed, 26 Mar 2003 03:43:07 +1200
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,
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:mono-list-
> email@example.com] On Behalf Of Paolo Molaro
> Sent: Wednesday, 26 March 2003 12:30 a.m.
> To: firstname.lastname@example.org
> 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
> > > same way with respect to returning (or not) exceptions. The MSDN
> > > describe exactly what exceptions/return codes File.Exists and
> > File.Open
> > > should return, Mono should do the same (unless the docs are in
> > A
> > > lot of work has already been done on this. You'll notice that many
> > > the test cases test whether or not the correct exception is being
> > > returned.
> > Definitely. I was more referring to our own class libraries (such
> > 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
> 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
> 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
> -> 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
> email@example.com debian/rules
> firstname.lastname@example.org Monkeys do it better
> Mono-list maillist - Monoemail@example.com
> 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