[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] load/startup time error handling

  • To: Hannes Mehnert <hannes@xxxxxxxxxxx>, "mirageos-devel@xxxxxxxxxxxxxxxxxxxx" <mirageos-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Drup <drupyog+caml@xxxxxxxx>
  • Date: Fri, 30 Sep 2016 18:37:06 +0200
  • Delivery-date: Fri, 30 Sep 2016 16:37:23 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=subject:to:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type; b=htVTJElnS7qxhWYq0gNHF7vqF1TaI41DHE1LMQ+lOgVeye0H5tYwnjjS0R8A2SIGkUvS17gwPiN8 92lntYglS75FCVLIMaanPokMpD26zzb5UTVLCNdQ5qJGRaRdUh4C
  • List-id: Developer list for MirageOS <mirageos-devel.lists.xenproject.org>

I was hoping we could add a `pp_error` function everywhere, and have something like `Error x -> fail (Device.pp_errror x)`
Apparently, that was more complicated than I expected.

In the end, I think you are right. Furthermore, Lwt has a built in error type (via Lwt.fail), so if someone want to do some fancy error handling later on, it should still be possible.

Le 30/09/2016 à 18:13, Hannes Mehnert a écrit :

There has been lots of threads about error reporting (both on this list
and in several issues).  I want to focus in here only on _load time
errors_ - which happen during startup (exactly when `connect` is
called).  Please leave run time error handling out of this thread.

So far, connect returns [ `Ok of 'a | `Error of 'b ] Lwt.t, and in the
error case functoria emits a "fail (Failure <devicename>)".  This is
clearly not very informative to potential users (an example being
"Failure net11").

I've iterated over the potential solutions with Mindy some days ago, and
wanted to ask the broader developer community: is there any non-fatal
initialisation error you can think of?  I cannot think of any (and
couldn't find any in various libraries I looked into).  I also cannot
think of actions you'd like to do when a failure occurs during startup
(apart from fixing the code, recompiling, and restarting).

Because, if not, we can simplify this rather radically by having connect
return an 'a Lwt.t, and in case of an error (such as "permission denied"
in mirage-net-unix) fail and never transit into running state of the

This would also, as a side effect, simplify run time errors since the
type error would not need to be convoluted with the potential startup
errors as it is the case now.

If nobody disagrees (and comes up with non-contrived examples), I'm
happy to massage code into this direction within the next few days.

Thanks for reading,


MirageOS-devel mailing list

MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.