Rodrigo Kumpera wrote: > 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.
I did not propose this. The idea was to always return the error status: MonoString *str; int status = mono_string_new_wrapper ("foo", &str); instead of MonoString *str = mono_string_new_wrapper ("foo", &error); Robert > > > 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 _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list