[Mono-dev] Error handling for embedded Mono

Paolo Molaro lupus at ximian.com
Mon Dec 4 13:54:19 EST 2006


On 12/01/06 luke at quinane.id.au wrote:
> I had a look at making some changes to remove some of these calls but ran
> into some problems. For example mono_init_internal calls exit (line 586 of
> domain.c) but by that point the domain has been allocated and a lot of
> things have been initialized. So my question is how does Mono handle such
> errors? Is it possible to return NULL for the domain and just call
> mono_jit_cleanup?

There are a few different cases where we have exit calls or asserts:
*) true-asserts: these should really never happen and they are there to
detect some errors, mostly in the internal usage of the API
*) asserts that hit incorrect uses of the embedding API: sometimes the
internal and embedding API overlap, so the same comment as above
applies, though we must make sure we have better error messages for
developers than asserts. In many cases here I think it's OK to exit,
because it compels the developer to fix his code (I always hate when
some gtk apps spwe lots of critical awarnings and they get never
fixed...)
*) basic configuration issues: a damaged corlib, or a corlib missing
System.Int32, say, would warrant an exit with an error. We need to take
some things for granted, otherwise we end up with half of the code doing
cleanup of a partially initialized runtime.
*) in all the other cases we should properly return an error indication:
work in this area is ongoing and help is highly appreciated.

> Also should mono_runtime_run_main (in object.c) set
> mono_environment_exitcode_set and return -1 instead of calling exit?

Maybe, though in such case it's likely better to have
mono_utf8_from_external () fall-back to consider the string to be in
latin1 encoding and so avoid the need to handle the error case there.

Thanks!

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better



More information about the Mono-devel-list mailing list