There are a few issues with using TLS for offloading error information: The first is that we must always copy information into it so we don't hold onto stale and possibly invalid data. This means it can't be used in signal context.
The second is that the information there is not as reliable as passing it explicitly since, for example, if one place forgets to clean up and the other fails but doesn't set the TLS data we might see out of context errors - mono has a lot of those bugs due to how the loader error stuff works. It's harder to nest error handling contexts using TLS. To do it one has to first save locally all information from the nested error then insert the new one. Finally, it makes up for good consistency to not use the return value as a guard for error handling because there are cases where returning NULL can mean either a valid condition or error. On Thu, Aug 13, 2009 at 7:28 PM, Robert Jordan <robe...@gmx.net> wrote: > Hi, > > Zoltan Varga wrote: > > Hi, > > > > I still it would be easier to simply pass a int* or use an int return > > value, instead of a structure which needs to be initialized/cleaned up, > and > > store any excess state in TLS. This is because > > most code can't do anything with an error other than cleaning up and > passing > > it up to the > > caller. > > > > So the code below could look like: > > I like this. > > > > > err = foo (); > > if (err) > > Or the same pattern with excess state in TLS: > > if (foo ()) > MonoError *err = mono_get_last_error (); > ... > > Using the return value to signal an error condition > also makes the code more macro-able, e.g.: > > #define MONO_CHECK(x) do { if ((x)) > abort (mono_get_last_error_message ()); } while (0) > > #define MONO_TRY(x) if ((x)) goto cleanup > > > MONO_CHECK (foo ()); > > and > > MONO_TRY (foo ()); > ... > > cleanup: > > Robert > > > > > > > > Zoltan > > > > On Thu, Aug 13, 2009 at 11:26 PM, Rodrigo Kumpera <kump...@gmail.com> > wrote: > > > >> Hey, > >> > >> The attached patch implements the basics for the new MonoError struct > that > >> will be used for error handling in the runtime. > >> It has only the basics to support the current exceptions the runtime > handle > >> for it's operation. > >> > >> The usage is pretty much like the one in Paolo's email on the subject: > >> > >> gboolean do_stuff () { > >> MonoError error; > >> mono_error_init (&error, 0); > >> runtime_function_that_might_fail (..., &error) > >> if (!mono_error_is_ok (&error)) > >> goto fail; > >> return TRUE; > >> > >> fail: > >> mono_error_cleaup (&error); > >> return FALSE; //or raise an exception using mono_raise_exception > >> (mono_error_prepare_exception (&error)); > >> } > >> > >> The idea is to replace all error handling code with using this (loader > >> error, type exception_data and JIT's exception_type). > >> > >> Still open is how this would be integrated on 2.6 and if functions > should > >> error out if passed an already set error object. > >> The last point enables more concise code like: > >> > >> MonoError error; > >> MonoType *type = ...; > >> mono_error_init (&error); > >> MonoClass *class = mono_class_from_mono_type (type, &error); > >> mono_class_init (class, &error); > >> MonoMethod *method = mono_class_get_method_from_name (class, "Invoke", > 1, > >> &error); > >> if (!mono_error_ok (&error)) > >> return NULL; > >> return mono_runtime_invoke (method, NULL, params, NULL); > >> > >> I left behind some aditional features I would like to add to help > >> development, like logging, signaling a breakpoint and > >> asserting if setting a second error to the same MonoError. > >> > >> It would be a good time to hear the feeback on everyone about this, > >> specially embedders, since this will be the basis for > >> error handling of the new API comming in 2.8. > >> > >> Please comment, > >> Rodrigo > >> > >> > >> _______________________________________________ > >> Mono-devel-list mailing list > >> Mono-devel-list@lists.ximian.com > >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > >> > >> > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list@lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list