Re: [MirageOS-devel] Error handling in Mirage

[Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx>]

Would it make sense to enforce that there's a pretty printer or sexp 
representation or something for those abstract types, in the interests of 
debuggability? That would deal with the abstract type of id etc. Wouldn't it?

--  
Cheers,

R.



> On 10 Jul 2014, at 15:34, "Anil Madhavapeddy" <anil@xxxxxxxxxx> wrote:
> 
>> On 10 Jul 2014, at 14:13, David Scott <scott.dj@xxxxxxxxx> wrote:
>> 
>> This sounds sensible to me.
>> 
>> When debugging one of these fatal errors (e.g. 'Disconnected' which means: 
>> someone called 'disconnect' and then tried 'read' or 'write' afterwards) it 
>> would be useful to have more context. For example it would probably be good 
>> to add the device id to the exception so we know which disk it relates to. 
>> This could help us infer that the buggy code is in the FS driver running on 
>> disk 2 and not the irmin backend on disk 1. There might be other useful 
>> context which is more implementation-specific. We could either just log this 
>> to the console or we could encode it up as an Sexp.t and attach that to the 
>> exception too?
> 
> We need to be a little careful with adding the device `id` into the 
> exception, as it's abstract in the module type and can vary by device.  But I 
> guess this is moot with exceptions -- if you're specifically catching and 
> deconstructing it, you know the type of id since you caught it outside of a _.
> 
>> Since our top-level function is in the auto generated code:
>> 
>> let () =
>>  OS.Main.run (join [t1 ()])
>> 
>> For every exception we declare in our interface, should we pre-create a 
>> default exception handler which pretty-prints it? This could also explain to 
>> the unlucky user that this is a bug and should be reported on the issue 
>> tracker?
> 
> It would be nice if every `job` that was registered would act as a monitor 
> for its top-level exceptions.  An exception leaking up to one job shouldn't 
> kill another one even if they're running in the same unikernel.
> 
> 
>> BTW I've now forked the V1 interfaces into a V2, so feel free to propose 
>> concrete changes as pull requests!
> 
> Excellent!
> 
> -anil
> 
> 
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
This message and any attachment are intended solely for the addressee and may 
contain confidential information. If you have received this message in error, 
please send it back to me, and immediately delete it.   Please do not use, copy 
or disclose the information contained in this message or in any attachment.  
Any views or opinions expressed by the author of this email do not necessarily 
reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system, you 
are advised to perform your own checks. Email communications with the 
University of Nottingham may be monitored as permitted by UK legislation.





_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel