[Mono-dev] New error handling framework for mono

[Rodrigo Kumpera]

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 <robertj at 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 <kumpera at 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 at lists.ximian.com
> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >>
> >>
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090813/eacbd3ea/attachment.html