New MonoError API for 2.8

2 messages Options
Embed this post
Permalink
Rodrigo Kumpera

New MonoError API for 2.8

Reply Threaded More More options
Print post
Permalink
Hi,

Today landed the initial version (r144686) of the MonoError API that will eventually unify all error handling code in the runtime.
Here is an overview of how it's meant to be used across the runtime.

The central structure is MonoError, which carry success/error result and all details about what went wrong.

The usage model is that a MonoError object is defined at entry point functions or error contexts. Entry point functions
are things like icalls or trampoline'd functions; an error context is, for example, type loading, which has to trap the error
to itself.

All function that can set an error must call mono_error_init or mono_error_init_flags at its very beginning. This sets the result
as success so nothing else needs to be done unless an error happens. Error setting functions are modeled around the managed
exceptions that might be thrown in the end.

After all call sites that pass a MonoError there must be a call to mono_error_ok to check the result. If an error mono_error_cleanup
must be called as well.

The idea is to hook up all entrypoints and embedding API calls with a MonoError parameter. For public API functions we'll add
a _checked version of them and mark the former as deprecated. For internal functions we'll just change the signature.

Besides that, with MonoError in place, the plan is to remove all possible asserts from the runtime to make things less crashy.

There are a few concerns about how this currently are that deserves to be discussed:

-Should we backport this to 2.6? To me it makes sense to do so for ML2, but without exposing new API entrypoints.

-Right now the whole API is made of functions, should we move the functions used in the fast path to macros? This is basically
mono_error_init and mono_error_ok.

Please review the change and give some feedback about the design. r144688 changes mono_class_inflate_generic_type as an example.

Cheers,
Rodrigo

_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Sharique uddin Ahmed Farooqui

Re: New MonoError API for 2.8

Reply Threaded More More options
Print post
Permalink
Is it on the top of exception handling? and how it is different from it?

I thunk we should add it to 2.8.


On 10/23/09, Rodrigo Kumpera <[hidden email]> wrote:

> Hi,
>
> Today landed the initial version (r144686) of the MonoError API that will
> eventually unify all error handling code in the runtime.
> Here is an overview of how it's meant to be used across the runtime.
>
> The central structure is MonoError, which carry success/error result and all
> details about what went wrong.
>
> The usage model is that a MonoError object is defined at entry point
> functions or error contexts. Entry point functions
> are things like icalls or trampoline'd functions; an error context is, for
> example, type loading, which has to trap the error
> to itself.
>
> All function that can set an error must call mono_error_init or
> mono_error_init_flags at its very beginning. This sets the result
> as success so nothing else needs to be done unless an error happens. Error
> setting functions are modeled around the managed
> exceptions that might be thrown in the end.
>
> After all call sites that pass a MonoError there must be a call to
> mono_error_ok to check the result. If an error mono_error_cleanup
> must be called as well.
>
> The idea is to hook up all entrypoints and embedding API calls with a
> MonoError parameter. For public API functions we'll add
> a _checked version of them and mark the former as deprecated. For internal
> functions we'll just change the signature.
>
> Besides that, with MonoError in place, the plan is to remove all possible
> asserts from the runtime to make things less crashy.
>
> There are a few concerns about how this currently are that deserves to be
> discussed:
>
> -Should we backport this to 2.6? To me it makes sense to do so for ML2, but
> without exposing new API entrypoints.
>
> -Right now the whole API is made of functions, should we move the functions
> used in the fast path to macros? This is basically
> mono_error_init and mono_error_ok.
>
> Please review the change and give some feedback about the design. r144688
> changes mono_class_inflate_generic_type as an example.
>
> Cheers,
> Rodrigo
>


--
Sharique uddin Ahmed Farooqui
(C++/C# Developer, IT Consultant)
http://safknw.blogspot.com/
"Peace" is the Ultimate thing we want.
_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list