Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

["Yuri K. Shatroff" <yks-uno@yandex.ru>]

24.02.2014 05:07, Alan McKinnon wrote:
[ ...]

> We don't do error handling. We don't even try and deal with it at the
> point it occurred, we just chuck it back up the stack, essentially
> giving them message "stuff it, I'm not dealing with this. You called me,
> you fix it."
>
> Doesn't sound like good design does it? Sounds more like do whatever you
> think you can get away with. Good design in this area gives you
> something conceptually along the lines of try...catch...finally (with
> possibly some work done to avoid throwing another exception in the
> finally).

try...catch...finally *does* leave error handling to *the caller*. It 
only provides a more object-oriented way to error handling. It *does 
not* *handle* errors.

> Unix error "design" does this:
>
> exit <some arb number>
> and an error message is in $@ if you feel like looking for it

Please, propose a more sound design? Take e.g. jQuery where all errors 
are handled by the library, it sometimes takes ages to debug why it 
doesn't work as expected, after a while you eagerly figure why error 
handling *should* be done by the caller, and the only thing the callee 
can do reliably is pass an error message upstream. Good error messages 
(and error codes, or error class hierarchy) are a different problem, but 
I haven't seen a more proof solution yet.

> Strangely, this approach is exactly why Unix took off and got such
> widespread adoption throughout the 70s. An engineer will understand that
> a well-thought out design that is theoretically correct requires an
> underlying design that is consistent. In the 70s, hardware consistency
> was a joke - every installation was different. Consistent error handling
> would severely limit the arches this new OS could run on. By taking a
> "Stuff it, you deal with it coz I'm not!" approach, the handling was
> fobbed off to a higher layer that was a) not really able to deal with it
> and b) at least in a position to try *something*.
>
> By ripping out the theoretical correctness aspects, devs were left with
> something that actually could compile and run. You had to bolt on your
> own fancy bits to make it reliable but eventually over time these things
> too stabilized into a consistent pattern (mostly by hardware vendors
> going bankrupt and their stuff leaving the playing field)
>
> And so we come to what "Unix design" probably really is:
>
> "You do what you have to to get the job done, the simpler the better,
> but I'm not *really* gonna hold you to that."

A good design is based on:
- consistency
- isolation and substitution of components
- component reuse
- thorough documentation
(a free interpretation of [1])

This almost always leads to many simple components, and that is what's 
called Unix design principles AFAIU.

The problem of Unix is that it doesn't follow "Unix design principles" 
any more. But it doesn't invalidate *the principles*.

> I still don't like what Lennart has done with this project, but I also
> fail to see what design principle he has violated.

As per [1], I fail to see what design principle he has followed.

[1] http://en.wikipedia.org/wiki/Software_design#Design_concepts

-- 
Regards,
Yuri K. Shatroff