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

[Thomas Leonard <talex5@xxxxxxxxx>]

On 30 September 2016 at 17:13, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
> Hey,
>
> 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
> unikernel.
>
> 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.

Sounds good to me!

This also side-steps the previous argument about how to handle connect
functions that can never return errors (whether they should have a
fake error return for consistency with the other constructors).


-- 
talex5 (GitHub/Twitter)        http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

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