ZeroMQ's author on why exceptions are bad

[Jonathan Amsterdam]

http://www.250bpm.com/blog:4

A lovely discussion of the practical problems with exceptions,
inheritance, constructors and destructors. Practically an
advertisement for Go.

[Uriel]

The ensuing discussion in Hacker News is also quite amusing, seems
there is almost universal agreement that exceptions are a really bad
idea:

http://news.ycombinator.com/item?id=3953434

Makes you wonder where all the people refusing to try Go because it
lacks exception come from (Java?).

[André Moraes]

The sad part is that Go wasn't public in 2007. Maybe ZeroMQ could be called GoMQ



--
André Moraes
http://amoraes.info

[jimmy frasche]

∅MQ is a library meant to be used by lots of languages so that
strongly implies C (though for some reason they went C++ and then
wrote a C wrapper around it). If it were in Go it could only be used
in Go and not Python or Java or what have you.

However, I was considering doing a rewrite of it in pure Go since at
least 70% of the ∅MQ code is to provide similar mechanisms as to what
the Go runtime offers so I believe a pure Go implementation would if
nothing else be far simpler and easier to understand (though you could
make the same argument for Erlang and the Erlang version is just a
binding to libzmq). Unfortunately that requires understanding what the
actual extant ∅MQ C and C++ implementation does which is nontrivial:
http://www.zeromq.org/docs:omq-2-1-class-diagram

After the initial hump of figuring out what's going on it sounds like
a fun project and maybe some day I'll get around to it

[Darren Grant]

Great article! Indeed what use is an unhandled exception? All you can
do is log it somewhere for debugging and quit before any more damage
occurs.

Exceptions do a disservice to programming because the idioms
surrounding their use leave the distinction of error versus result as
an exercise for the programmer. At least the panic idioms makes it
very clear about the fact that something went horribly wrong. As a
developer new to Go I would not read about panic and then think that I
should recover based on an interpretation of the error string!

[Joubin Houshyar]

On May 10, 12:08 pm, Jonathan Amsterdam <jbamster...@gmail.com> wrote:
> http://www.250bpm.com/blog:4
>
> A lovely discussion of the practical problems with exceptions,

Martin is of course an excellent engineer but that appears to be a
lament of his approach to the use of exceptions ... in C++. Tales of
error from C++-land are frankly a yawn.

"If you don't give up on the "no undefined behaviour" principle,
you'll have to introduce new exception types all the time to
distinguish between different failure modes. However, adding a new
exception type means that it can bubble up to different places. Pieces
of code have to be added to all those places, otherwise you end up
with undefined behaviour."

3 categories of exceptions have proven to be entirely sufficient to
create clean modular and entirely comprehensible exception handling,
in Java.

1 - Fault. RuntimeTime. (Go's panic). Unexpected system error --
e.g. the network disappears. Typically Fault.cause() -> root issue.

2 - Error. Checked exception. These /may/ require further
elaboration. Per exposed public API.

3 - Bug. (Panic) Unexpected Throwable thrown anywhere and caught at
module boundary. Just like a Fault but understood at throw site to be
a programming error (e.g. expected byte sequence is not at the
beginning of a protocol msg, etc.)

> inheritance, constructors and destructors. Practically an
> advertisement for Go.

A true beauty attracts based on her own merit not the relative
comeliness of her rivals.

[Evan Shaw]

On Fri, May 11, 2012 at 8:00 AM, jimmy frasche <soapbo...@gmail.com> wrote:
> However, I was considering doing a rewrite of it in pure Go since at
> least 70% of the ∅MQ code is to provide similar mechanisms as to what
> the Go runtime offers so I believe a pure Go implementation would if
> nothing else be far simpler and easier to understand (though you could
> make the same argument for Erlang and the Erlang version is just a
> binding to libzmq). Unfortunately that requires understanding what the
> actual extant ∅MQ C and C++ implementation does which is nontrivial:
> http://www.zeromq.org/docs:omq-2-1-class-diagram

I'm reluctant to advertise this because it's in terrible shape and I'm
not really working on it anymore, but I wrote a partial implementation
in Go: https://github.com/edsrzf/zegomq

It was, at least at one point, working well enough to write a Mongrel2
handler. I think the ∅MQ wire protocol may have changed since then,
but I'm not sure.

- Evan

[GreatOdinsRaven]

On my day job, I do C#/Java. 

Exceptions *everywhere*. Used for exceptional conditions, control flow, normal errors, parallel task cancelation, the works. 

I don't claim to be a genius, but I have never, ever, ever struggled with how to properly use them. It's not rocket science. You *only* catch exceptions if you know you can handle them (or want to just re-wrap in another one for some reason, log something, whatever, then rethrow). If you don't know what to do with the exception...why are you catching it?

This has worked wonders for me. 

C++ guys however, especially the ones with more experience, seem to be struggling. I don't get it. The examples given are ridiculous - in all of the, the error handling has the same locality as the error throw. So of course C-style is "good enough" - that is the simplest of simplest cases. What if you can't handle it locally? What then? You have to unwind the stack yourself by calling return X number of times and bubbling the error up....or, you could let the compiler do that for you. And watch destructors get called auto-magically.....and RAII works....and everyone is happy? 

Isn't this what "modern" C++ is about? No destructors, no raw pointers, RAII and exceptions everywhere? Or am I missing something? 

And just like with Go, don't throw exceptions across library boundaries - those stay inside the library, use errors externally. 

I think there's got to be something I'm not seeing, but C++ guys just seem the most confused on how to do error handling than any other programmers out there. What's going on? 

[Graham Anderson]

On Thursday 10 May 2012 13:27:21 Joubin Houshyar wrote:
> 1 - Fault. RuntimeTime. (Go's panic). Unexpected system error --
> e.g. the network disappears. Typically Fault.cause() -> root issue.
>

> 2 - Error. Checked exception. These may require further

> elaboration. Per exposed public API.
>
> 3 - Bug. (Panic) Unexpected Throwable thrown anywhere and caught at
> module boundary. Just like a Fault but understood at throw site to be
> a programming error (e.g. expected byte sequence is not at the
> beginning of a protocol msg, etc.)

And you still have a spaghetti soup of what fired from where and how did that
codepath get chosen.

And in your excessive control flow view of the logical world; *why* does the
code look so complicated for such simple problems, and why does it take me so
long to load the code into my brain when I already understand the problem
without having extraneous/superflous keywords or language fluff.

> A true beauty attracts based on her own merit not the relative
> comeliness of her rivals.

Man is the source and cause of beauty. Man mirrors himself on the world and
reflects the beauty that resides within him upon the world.

[Paulo Pinto]

That has always been the case. I imagine it lays on the C heritage
from many of
them.

When I learned C and later on moved to C++, I was already quite
proficient in Turbo
Pascal, Modula-2...

So I never understood the lengthy articles in The C Users Journal, The
C/C++ Users Journal
and C++ Report how to organize the code in namespaces or handle
exceptions.

Somehow having experienced those features in more saner languages, I
never grasped
why they were hard subjects.

--
Paulo

On May 11, 2:51 am, GreatOdinsRaven <dimiter.velich...@gmail.com>
wrote:

> On my day job, I do C#/Java.
> Exceptions *everywhere*. Used for exceptional conditions, control flow,
> normal errors, parallel task cancelation, the works.
> I don't claim to be a genius, but I have never, ever, ever struggled with
> how to properly use them. It's not rocket science. You *only* catch
> exceptions if you know you can handle them (or want to just re-wrap in
> another one for some reason, log something, whatever, then rethrow). If you
> don't know what to do with the exception...why are you catching it?
>
> This has worked wonders for me.
>

> C++ guys however, especially the ones with *more* experience, seem to be

[Matt Joiner]

I've always claimed that C++ exceptions are just awful. C++ gives exceptions a really bad name, and many never move onto, or back to another language that does it well. I've had excellent experience with exception handling in Python and Haskell. In particular in Python, exceptions contain fully debuggable stack and traceback information, and a complete set of statements to work with exceptions properly. try/else/except/finally. The exception hierarchy is also much better defined. C++ lacks a finally clause, and other niceties, and forces its half baked OO model onto you if you want to use exceptions "properly".

That said, exceptions are one of those language features that just begs to be misused. I agree with Martin in that the fact that C *lacks* many of these dangerous constructs is one of its greatest appeals. He, I, and many others would prefer they just weren't available because they are inevitably deployed by some colleague or other.

The (poor) use of C++ shows in zeromq, I've always found it highly volatile, and its interoperability suffers. Cryptic error messages the result of unhandled exceptions abound in my testing of it.

I doubt Go is a consideration for zeromq's implementation, its own interoperability is still the biggest drawback it has. 

[SteveD]

On Thursday, May 10, 2012 6:08:28 PM UTC+2, Jonathan Amsterdam wrote:

A lovely discussion of the practical problems with exceptions,
inheritance, constructors and destructors. Practically an
advertisement for Go.

For a piece of basic infrastructure like that, he would be better off doing it all in old-fashioned, careful C.  Less magic, and he would not be flamed by C++ supporters.  (C people are much nicer.)

As are Go people, of course ;)

It would be interesting to see how a Go implementation performs...

steve d.

[si guy]

C# exceptions can hurt performance if used for control flow too much, sometimes I think the runtime is having a heart attack :)