[ja30278]

1. Exceptions are basically 'goto' with a pretty wrapper. Over time, I've come to believe that the best place to handle an error is close to where it occurs, rather than throwing some hail mary message up the stack and hope someone else can deal with it.

2. Well, it certainly is true that more code and more functionality is likely to contain more bugs. Whether your pid 1 needs to be doing all the things that upstart does is obviously a contentious issue.

3. This is a toss-up. I usually like 'crash loudly' over 'fail silently', but I think rejecting the patch outright was a poor decision.

[gohrt]

> Exceptions are basically 'goto' with a pretty wrapper.

Famously, "for loops" are basically 'goto' with a pretty wrapper.

[cbd1984]

> Famously, "for loops" are basically 'goto' with a pretty wrapper.

Trivial response: for loops don't potentially involve jumping into code in a completely different file, which could have been written by someone else.

More substantive response: for loops don't imply a specific philosophy about error handling.

That said, I do like exceptions, as I think they encourage a healthy ignorance in most code, as long as the code which can handle the exception does handle it. But that's just a "don't write bad code" admonition, and you can abuse any philosophy to write bad code.

[3pt14159]

1. It is a different mindset. Handling each error code until your program is correct top to bottom makes for a much more stable existence, but it's harder when you rely on something that hasn't handled an error code. With exceptions it is easier to work with shitty middleware. Also, in environments where exceptions are idiomatic, there are ways of cleaning up aborted code and safely entering exception handlers. Far more straightforward to reason about than `GOTO 34550`.

I agree with your other two points though.