1 |
24.02.2014 05:07, Alan McKinnon wrote: |
2 |
[ ...] |
3 |
|
4 |
> We don't do error handling. We don't even try and deal with it at the |
5 |
> point it occurred, we just chuck it back up the stack, essentially |
6 |
> giving them message "stuff it, I'm not dealing with this. You called me, |
7 |
> you fix it." |
8 |
> |
9 |
> Doesn't sound like good design does it? Sounds more like do whatever you |
10 |
> think you can get away with. Good design in this area gives you |
11 |
> something conceptually along the lines of try...catch...finally (with |
12 |
> possibly some work done to avoid throwing another exception in the |
13 |
> finally). |
14 |
|
15 |
try...catch...finally *does* leave error handling to *the caller*. It |
16 |
only provides a more object-oriented way to error handling. It *does |
17 |
not* *handle* errors. |
18 |
|
19 |
> Unix error "design" does this: |
20 |
> |
21 |
> exit <some arb number> |
22 |
> and an error message is in $@ if you feel like looking for it |
23 |
|
24 |
Please, propose a more sound design? Take e.g. jQuery where all errors |
25 |
are handled by the library, it sometimes takes ages to debug why it |
26 |
doesn't work as expected, after a while you eagerly figure why error |
27 |
handling *should* be done by the caller, and the only thing the callee |
28 |
can do reliably is pass an error message upstream. Good error messages |
29 |
(and error codes, or error class hierarchy) are a different problem, but |
30 |
I haven't seen a more proof solution yet. |
31 |
|
32 |
> Strangely, this approach is exactly why Unix took off and got such |
33 |
> widespread adoption throughout the 70s. An engineer will understand that |
34 |
> a well-thought out design that is theoretically correct requires an |
35 |
> underlying design that is consistent. In the 70s, hardware consistency |
36 |
> was a joke - every installation was different. Consistent error handling |
37 |
> would severely limit the arches this new OS could run on. By taking a |
38 |
> "Stuff it, you deal with it coz I'm not!" approach, the handling was |
39 |
> fobbed off to a higher layer that was a) not really able to deal with it |
40 |
> and b) at least in a position to try *something*. |
41 |
> |
42 |
> By ripping out the theoretical correctness aspects, devs were left with |
43 |
> something that actually could compile and run. You had to bolt on your |
44 |
> own fancy bits to make it reliable but eventually over time these things |
45 |
> too stabilized into a consistent pattern (mostly by hardware vendors |
46 |
> going bankrupt and their stuff leaving the playing field) |
47 |
> |
48 |
> And so we come to what "Unix design" probably really is: |
49 |
> |
50 |
> "You do what you have to to get the job done, the simpler the better, |
51 |
> but I'm not *really* gonna hold you to that." |
52 |
|
53 |
A good design is based on: |
54 |
- consistency |
55 |
- isolation and substitution of components |
56 |
- component reuse |
57 |
- thorough documentation |
58 |
(a free interpretation of [1]) |
59 |
|
60 |
This almost always leads to many simple components, and that is what's |
61 |
called Unix design principles AFAIU. |
62 |
|
63 |
The problem of Unix is that it doesn't follow "Unix design principles" |
64 |
any more. But it doesn't invalidate *the principles*. |
65 |
|
66 |
> I still don't like what Lennart has done with this project, but I also |
67 |
> fail to see what design principle he has violated. |
68 |
|
69 |
As per [1], I fail to see what design principle he has followed. |
70 |
|
71 |
[1] http://en.wikipedia.org/wiki/Software_design#Design_concepts |
72 |
|
73 |
-- |
74 |
Regards, |
75 |
Yuri K. Shatroff |