It's a good alternative, and changing return values isn't an issue since we'll pretty much change all signatures in the runtime anyway.
Using the return value makes it easier to write macros to remove a lot of boiler plate code. On Thu, Aug 13, 2009 at 8:23 PM, Zoltan Varga <var...@gmail.com> wrote: > Hi, > > Its possible to only use the return value for error checking, we did at > Nokia, and it worked > fine, although it would require returning values using an out parameter. It > simplified error > checking code significally, since every function returned the same > ErrorCode value. > > Zoltan > > > 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 >> >> >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list