Hi T.J.,

Sorry for the terse reply at first; I didn't have a lot of time to look at
it in great detail (I've only read the first few sections and conclusion so
far). I must also confess that my domain of expertise is in distributed
computing, not programming languages, so please take my thoughts on this
work with a grain of salt :)

If I understood correctly, the researchers created and evaluated a hybrid
static analysis/runtime verification technique (a compensation stack) that
allows a program to guarantee certain safety properties regarding resource
usages. They focus specifically on exceptional cases where resource
availability changes due to external factors beyond the program's control
(such as disk I/O failing, or a network partition occurring). From a
practical standpoint, the system focuses on ease of use: the developer
writes a safety policy and declares which (supported) resources a set of
methods can access, and the compiler ensures that the resulting program
exhibits behavior consistent with the policy.

I would totally use a system like this for distributed systems
programming. I read a paper a while back that suggested that major errors
in popular distributed systems come from not handling certain exceptions
correctly [1]. It would be interesting to see what percentage of these
errors would be handled by the technique presented here, and I suspect this
technique would go a long way toward mitigating them.

Personally, I try to avoid exception-handling altogether when possible in
favor of plain old C-style error codes. I don't like how the non-local
nature of exception handling can allow an uncaught exception to propagate
through the call stack and get caught (and incorrectly handled) somewhere
else. As such, I make it a habit to encapsulate all "unsafe"
(exception-generating) behaviors like I/O into their own methods with
catch-all exception handlers to keep their side-effects isolated and easy
to reason about, and I try to do all unsafe behavior in one "big step" so
the program can fail fast before taking any partial actions on it (heh,
maybe one day I'll go full FP).

I'm not really a fan of garbage collection for system-level code (I just
use valgrind instead to catch leaks early and often), but can .NET actually
leak memory? What's the point of it having a garbage collector then? Heh,
good thing the CLI got open-sourced--at least we can fix it if so!

Best,
-Jude

[1]
https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf

On Fri, Dec 19, 2014 at 7:54 PM, T.J. Duchene <t.j.duchene@???> wrote:
>
>
>
>
>
> *From:* Jude Nelson [mailto:judecn@gmail.com]
> *Sent:* Friday, December 19, 2014 4:03 PM
> *To:* T.J. Duchene
> *Cc:* dng@???
> *Subject:* Re: [Dng] Study
>
>
>
> Thanks for the interesting paper!
>
>
>
> You're very welcome, Jude. =) I hope it is useful. I certainly found
> what I had time to read enlightening. I'd like to find out your
> impressions of it sometime, as it relates to C++, your apparent language of
> choice. Right now, I'm having the joys of another modern language feature
> that drives me to distractions: garbage collection. I've to go through a
> bunch of .NET code looking for potential leaks. Right now, I miss standard
> C++
>
>
> See you!
> T.J.
>
>
>
>
> On Fri, Dec 19, 2014 at 4:08 PM, T.J. Duchene <t.j.duchene@???>
> wrote:
>
>
> http://www.cs.virginia.edu/~weimer/p/weimer-toplas2008.pdf
>
> I was skimming this and thought the programmers on the list might like it
> as
> well. I never read any of the research being done on programming semantics
> over at Berkeley, but this one is definitely interesting. You definitely
> won't look at Java, C++, or C# the same way afterward. Some of the cases
> they make against exception handlers are rather disconcerting, considering
> how often they are used these days.
>
> Have a great day,
> T.J.
>
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>