> Personally, I've found exceptions too unwieldy. As I mentioned, the issue of > catching an exception is "now, how do I recover ?".
In my experience it's not really a problem. Usually you just gracefully report an error and either exit the program, or write error to log and stop the operation. > Note that Rust and Go do have exceptions (and unwinding), it's just that you > have to create a dedicated task instead of a try/catch block. I can see the advantages of this solution. The only thing I don't see is how to pass any meaningful state with an error. On Fri, May 30, 2014 at 9:32 AM, Matthieu Monrocq <[email protected]> wrote: > > > > On Fri, May 30, 2014 at 2:01 AM, Oleg Eterevsky <[email protected]> wrote: >> >> > Since browsers were brought up, here is the Google C++ style guide on >> exceptions: >> > >> > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions >> >> As someone who works for Google, I can attest, that exceptions are >> encouraged in Google style guides for Python and Java and the main >> reason they are forbidden in C++ is their memory safety. Google has a >> big amount of pre-exceptions C++ code, and it will break in unexpected >> places if exceptions are allowed. >> > > Yes, which is a common issue. Exception usage requires exception-safe code. > But then, exception-safe code is also code resilient in the face of > introducing other return paths so it's just overall better whether in the > presence of exceptions or not... > >> >> Go is a different story. It deliberately refuses to support exceptions >> even though it has GC and hence has no problems with exception memory >> safety whatsoever. The lack of exception might be one of the main >> reasons (if not the main reason), why Go is not so popular even within >> Google. >> > > Personally, I've found exceptions too unwieldy. As I mentioned, the issue of > catching an exception is "now, how do I recover ?". > > Note that Rust and Go do have exceptions (and unwinding), it's just that you > have to create a dedicated task instead of a try/catch block. Indeed, it's > more verbose (which is mostly a matter of libraries/macros) and it's also > less efficient (which could be addressed, though at compiler level); however > it's just plain safer: now that shared-state/updates to the external world > are explicit, you can much more easily evaluate what it takes to recover. > > >> >> On Thu, May 29, 2014 at 4:39 PM, comex <[email protected]> wrote: >> > On Thu, May 29, 2014 at 7:10 PM, Oleg Eterevsky <[email protected]> >> > wrote: >> >> The projects in C++ that forbid exceptions are doing so not because of >> >> some prejudice, but because exceptions in C++ are unsafe. In Java >> >> standard library exceptions are ubiquitous. >> > >> > If you mean checked exceptions, I hear that they're quite unpopular, >> > although I don't use Java. >> > >> > Since browsers were brought up, here is the Google C++ style guide on >> > exceptions: >> > >> > >> > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions >> > >> > It bans them due to a variety of downsides which would only be >> > partially addressed by checked-exception-like safety systems. I think >> > Google Java code does use exceptions, but that's language culture for >> > you. >> > >> > As a related data point, Go eschews exceptions entirely due to >> > prejudice: >> > >> > http://golang.org/doc/faq#exceptions >> > >> > Not that I agree with most of Go's design decisions... still, I think >> > these examples are enough to demonstrate that there are legitimate >> > reasons to prefer a language designed without exceptions. >> > >> > I think it may be good for you to get more experience with Rust, >> > although as I mentioned, I also lack experience. >> _______________________________________________ >> Rust-dev mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
