[Mono-dev] New error handling framework for mono

[Rodrigo Kumpera]

I'm ok with using TLS for storing error information. The only issue is that
we must be carefull to avoid stale
data. The thing is that ErrorCode should be a struct so it can't be confused
with an ordinary int.

OTOH, we could do it like posix does for mutexes and get rid of the
initializer function:

MonoError error = MONO_ERROR_INITIALIZER;



On Thu, Aug 13, 2009 at 6:49 PM, Zoltan Varga <vargaz at gmail.com> wrote:

>
> So the code below could look like:
>
>   ErrorCode err;
>
>   err = foo ();
>   if (err)
>      goto fail;
>
> fail:
>    <cleanup>
>    return err;
>
>
> On Thu, Aug 13, 2009 at 11:48 PM, Zoltan Varga <vargaz at gmail.com> 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:
>>
>>   err = foo ();
>>   if (err)
>>
>>
>>                                  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
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090813/6f455d9b/attachment.html