[Mono-dev] New MonoError API for 2.8

Sharique uddin Ahmed Farooqui safknw at gmail.com
Sat Oct 24 02:30:04 EDT 2009


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 <kumpera at gmail.com> 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.


More information about the Mono-devel-list mailing list