| 1 |
On Sun, Feb 23, 2014 at 8:10 PM, Walter Dnes <waltdnes@××××××××.org> wrote: |
| 2 |
> On Mon, Feb 24, 2014 at 03:07:09AM +0200, Alan McKinnon wrote |
| 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 |
> The developer is not going to be psychic to the point of knowing what |
| 10 |
> the user *WANTED* to do, years after the code was written... or which |
| 11 |
> different users were expecting which different outcomes. E.g. if |
| 12 |
> portage encounters a problem during a build, do you *REALLY* want it to |
| 13 |
> jump in and randomly patch source code and/or makefiles to get it |
| 14 |
> working? NO!!! You want it to halt, with an informative error message, |
| 15 |
> possibly including suggestions for corrective action. |
| 16 |
|
| 17 |
But in Unix you usually don't halt, you set errno and go on your merry way. |
| 18 |
|
| 19 |
> If I mistakenly |
| 20 |
> tell a system to do B, really meaning do A, that's my fault. If I tell |
| 21 |
> it to do A, and it decides to do B, I will be extremely p'd off. |
| 22 |
|
| 23 |
I don't see what does that have to do with any of Alan's points. |
| 24 |
|
| 25 |
Regards. |
| 26 |
-- |
| 27 |
Canek Peláez Valdés |
| 28 |
Posgrado en Ciencia e Ingeniería de la Computación |
| 29 |
Universidad Nacional Autónoma de México |
Archives