7 ms·

Notably, exceptions are not used. Instead errors are handled with assertions and error objects.

by Rarebox 10y ago

adamnemecek 10y ago
I feel like people are realizing that exceptions were a bad idea. They are kind of like gotos.
- SamReidHughes 10y ago
  C++ is memory-unsafe and has a special relationship with the feature. Projects that start without pervasive exception safety in mind are usually stuck that way.
- evincarofautumn 10y ago
  Exceptions are much worse than “goto”, in my experience. “throw” is basically a dynamically bound “return” statement—it’s hard to reason about where you’ll end up, because it depends on the call stack above you, and the type of object you decided to throw. The same throw site might jump to many different, unrelated parts of the program. Real exception safety is almost as hard to get right as concurrency, and for similar reasons.
  - adamnemecek 10y ago
    I was referring to old school gotos, not like those in c. But yeah, we are in the same page.
  - slezyr 10y ago
    > Real exception safety is almost as hard to get right as concurrency, and for similar reasons It's even harder to get right concurrency with exceptions :D
    - quotemstr 10y ago
      > It's even harder to get right concurrency with exceptions No it isn't.
  - Chris_Newton 10y ago
    I can’t help noticing that much of your objection applies just as much to return as to throw. Isn’t the point, in both cases, that you shouldn’t need to reason about where you’ll end up? Either your function can complete its task successfully, in which case it satisfies whatever invariants are required of it and returns accordingly, or it can’t, in which case it can throw an exception to indicate that inability to return successfully. In the success case, the calling code can then continue based on whatever returned value and/or side effects the function was supposed to provide. In the failure case, the calling code may well fail itself if it can also no longer complete its task successfully, and so on up the stack until you reach a level in your design that knows how to recover from the failure or stop the entire program gracefully, which is where you catch the exception. I’ve never quite understood the idea that exceptions are similar to goto. Other than transferring control over potentially long “distances” within a program, they don’t seem to have much in common at all. To me, a much closer analogy would be returning early from a function on success, if you reach a point in your algorithm where you already know the required answer to whatever question your calling code was asking. Another similar situation would be using a break or continue statement to finish an iteration early within a loop, or adding extra guard cases to stop a recursion early, again if you already know the outcome and continuing with the full algorithm has no advantage.
    - evincarofautumn 10y ago
      > I can’t help noticing that much of your objection applies just as much to return as to throw. Isn’t the point, in both cases, that you shouldn’t need to reason about where you’ll end up? That is the point, but my specific objection is to the dynamic binding and dynamic typing, not the returning. With “return”, even early return, you don’t really need to reason about where you’ll end up at all—it’s always the end of the current function. And the same goes for functions that throw exceptions directly. The problem is that when you have unchecked exceptions, any function can throw, so every function call in your code is now also a potential early return, and for correct code you need to account for that.
    - pjc50 10y ago
      The real failure is that return types must be declared by exceptions need not be and generally aren't. So an exception can come teleporting through any part of your code. You can no longer enforce single return style, because any expression can return. This means that writing state-modifying code becomes unreasonably difficult, as you can no longer just write: // A and B must be kept in sync and updated together A = computeA() B = computeB() .. because it's possible that computeB() throws an exception, leaving the two out of sync. Yes, there are ways round this involving temporary variables. So you write: tmpA = computeA() tmpB = computeB() A = tmpA, B = tmpB; and home that neither an optimiser nor an intern removes the tmp variables. But wait! This still doesn't work, because your evil coworker has defined operator= on B to throw an exception! Personally I don't think that exceptions work very well in the presence of mutable state. Without mutable state, they're exactly equivalent to
- pjmlp 10y ago
  It is very hard to make libraries that rely on features that can be turned off. The bad idea was making language features optional. Library writers are forced to either support all possible combinations, don't use any of them or use them and see their library being rejected by those that won't turn on the features even at point gun. One of the things that made me initially enjoy Java was that there weren't features to turn on or off.
  - adamnemecek 10y ago
    You are correct but all those books on cpp exceptions are about a bit more than dealing with issues related to optionally disabling them :-).
    - pjmlp 10y ago
      Agree, but that is because when compared with other languages exceptions in C++ were always bolted on. They don't play well with manual memory management or the C semantics C++ was trying to be as compatible as possible. They don't play well with: - constructors/destructors - manual resource management - low level code like UNIX signals - allowing every possible type to be used as exception So all of that made C++ exceptions poor cousins of how exceptions are used in other languages. I have used exceptions in quite a few languages and rather use them (the alternative being sum types), but do understand that how C++ evolved they are an unwelcome feature.
      - quotemstr 10y ago
        It's only exceptions that allow constructors to work properly and that allow the language to support value type management. Without exceptions, you need two-phase initialization, and that's a nightmare.
        pjmlp 10y ago
        I hate two-phase initialization with passion, specially the way it was done in Symbian C++.
- zvrba 10y ago
  You're funny. gotos are used to emulate cleanup both of which you get in a more structured manner with RAII and exceptions. Rmember Apple's infamous "goto bug" in OpenSSL?
  - adamnemecek 10y ago
    I'm well aware. I was talking about old school gotos, I should have probably said that.
  - Peaker 10y ago
    While RAII and exceptions are better than goto's, the "goto fail" bug is not an example of that. The problem there was mismatch between indentation and parse which was a result of brace-less style and whitespace-insensitivity.
- cyphar 10y ago
  Except gotos are legitimately useful for cleanup inside a function before you return an error (see: the Linux kernel). Exceptions have overhead, and you have no idea where it will end up because the exception will bubble up the current call-stack, while gotos are local to the current function (and while longjmp is a mess, it is useful if you use clone(2)).
  - adamnemecek 10y ago
    I'm well aware. I was talking about old school gotos, I should have probably said that.
  - vvanders 10y ago
    You should be using RAII for any resources that you need to automatically clean up, then any return statement will catch it. No need for exceptions.
    - cyphar 10y ago
      RAII is not a feature of C. I was commenting on how gotos are not like exceptions, because gotos are actually useful and don't cause your program to make less sense as a result.
- IshKebab 10y ago
  Yeah finally. The problem with exceptions is that you lose context about where the error occurred, and you really need to know that to handle the error properly. That's why most exception handlers just print the error. I think the only situation where exceptions help is in constructors, but there are better solutions to that problem, like explicit object construction methods that can return an error. I think Go's approach to error handling is the best - explicit and in context. Rust's `Result` looks quite nice though I haven' tried it yet.
  - barrkel 10y ago
    Most errors shouldn't be handled; that's the reason most exception handlers simply log the error. I've said it here before, but this is my classification of errors that exceptions are commonly used for: 1) Programming error: null pointer exception, library invariants broken, etc. These generally shouldn't be caught, and could arguably be replaced by fatal assertions, but that's typically not a polite thing to do in a library. 2) Non-deterministic failure condition: something outside the control of the calling code failed in a way that it cannot predict ahead of time. A network connection broke, a file was deleted unexpectedly, a device was detached, database server died, etc. There's something of an argument for annotating functions that can fail this way in the manner of Java's checked exceptions and it has a strong relationship with the IO monad in Haskell (and similar problems with encapsulation and hiding implementation details). These kinds of errors can sometimes be handled, and handling them with exceptions isn't much better or worse than error codes. An advantage of exceptions is that they makes it easy to abort the whole task and go back to the request handler (server code) or event dispatch loop (UI code). Exceptions can carry more state than error codes, too. 3) Business logic problem: the user, for want of a better term, of the program tried to do something that is not allowed / possible, and the program needs to abort the current task and inform the user of the problem. Exceptions are as good a means of aborting as most others. These should only be caught at the top level, whereupon they can be converted into something for human / 422 response / whatever consumption. In almost all cases, you cannot proceed and there is nothing you can do in reaction to the error. Aborting and unwinding the call stack is usually the correct thing to do.
  - clappski 10y ago
- pif 10y ago
  When used for exceptional things, exceptions are wonderful. But they were never meant to completely replace status-related exit codes. Expected errors (ex: log file does not exist, so create a new one) are not to be treated via exceptions; exceptional errors (ex: no more memory available, and I'm just trying to allocate a few bytes) are.
- protomyth 10y ago
  I can see it in C++, but they seemed to work pretty well in Ada. A lot of things seem to work better in Ada to be truthful.
hacker_9 10y ago
This is actually really interesting to me. I use C# for side projects and often write Debug.Assert everywhere to check things, but can't quite bring myself to throw exceptions for full blown errors. I just find they add a lot of bloat, and don't really help the problem, they are just a lazy catch all. But I have to say returning Error<TResult> is a really elegant way of dealing with the problem, I think I will have to start doing it this way.
- barrkel 10y ago
  Returning an error type, and, in the caller, propagating that return type further up, is isomorphic to exceptions, except it's a lot more busywork, a lot more code bloat, and a lot easier to get wrong.
  - perspectivep 10y ago
    And you have to remember to log the error at every level of the stack, otherwise you're left with an error code that has no context.
  - yoklov 10y ago
    It's also encoded in the return type of the function, so you get static type checking -- a property not present for exceptions.
    - barrkel 10y ago
      You say that like it's desirable. I think Java's experience of checked exceptions shows that it's of very dubious benefit.
quotemstr 10y ago
C++ projects banning exceptions is a massive blunder. We should not disable important aspects of the language that provide useful semantic features to satisfy the anti-bloat superstitions of a few who remember bad C++ compilers of the 1990s. Nobody feels the need to create an exception-less variant of Java or Python, after all. A ban on C++ exceptions is a huge red flag for me. A project has to be really special if I'm going to contribute to it after it's crippled the language.
- bigcheesegs 10y ago
  The llvm-project is a compiler. Its developers are well aware of the true cost of exceptions.
  - barrkel 10y ago
    Actually, compilers typically don't use exceptions because they don't usually abort on the first instance of a problem. Compilation has historically been an lengthy batch job, and thus reporting many errors to be fixed between iterations improves user productivity.
    - favorited 10y ago
      I think the point was that LLVM compiler infrastructure has a first-class C++ font-end. They know the ins-and-outs of language features because they are implementing standards-compliant compilers for said language.
      - barrkel 10y ago
        Most self-hosted compilers are written in languages ill-suited to compiler writing. The choice of features used is often a compromise, rather than best practice for either good compiler design or good target language use. C++ users in particular have strong concerns about things like RTTI and the overhead of exceptions not thrown. The cost of making unthrown exceptions low (near zero) is that throwing exceptions is much more expensive. This turns into a feedback loop, where C++ programs end up performing better if they never throw any exceptions because of the tradeoff. This feeds into self-hosted compilers. Thing is, certain compiler design techniques can work well with cheap unwinding: constraint solving (more common in languages with better type systems than C++), forward-looking grammar assertions with speculative parsing, IDE-integrated code completion (implement the lexer to add the cursor position as a special token, and jump out of the parser when it's found, where all the context is available to pass along). But C++'s peculiar tradeoffs may make using things like exceptions less than ideal to use for this purpose, not because exceptions are the wrong tool, but because most C++ programs are not compilers and aren't tuned for it. And OTOH, compilers written in low-level languages like C++ often twist themselves into knots to simulate things like tree pattern matching, multiple dispatch, destructuring binds, etc. Sometimes they even give up and write code generating tools.

Notably, exceptions are not used. Instead errors are handled with assertions and error objects.

by Rarebox 10y ago

Notably, exceptions are not used. Instead errors are handled with assertions and error objects.

adamnemecek 10y ago

I feel like people are realizing that exceptions were a bad idea. They are kind of like gotos.

SamReidHughes 10y ago
C++ is memory-unsafe and has a special relationship with the feature. Projects that start without pervasive exception safety in mind are usually stuck that way.
evincarofautumn 10y ago
Exceptions are much worse than “goto”, in my experience. “throw” is basically a dynamically bound “return” statement—it’s hard to reason about where you’ll end up, because it depends on the call stack above you, and the type of object you decided to throw. The same throw site might jump to many different, unrelated parts of the program. Real exception safety is almost as hard to get right as concurrency, and for similar reasons.
- adamnemecek 10y ago
  I was referring to old school gotos, not like those in c. But yeah, we are in the same page.
- slezyr 10y ago
  > Real exception safety is almost as hard to get right as concurrency, and for similar reasons It's even harder to get right concurrency with exceptions :D
  - quotemstr 10y ago
    > It's even harder to get right concurrency with exceptions No it isn't.
- Chris_Newton 10y ago
  I can’t help noticing that much of your objection applies just as much to return as to throw. Isn’t the point, in both cases, that you shouldn’t need to reason about where you’ll end up? Either your function can complete its task successfully, in which case it satisfies whatever invariants are required of it and returns accordingly, or it can’t, in which case it can throw an exception to indicate that inability to return successfully. In the success case, the calling code can then continue based on whatever returned value and/or side effects the function was supposed to provide. In the failure case, the calling code may well fail itself if it can also no longer complete its task successfully, and so on up the stack until you reach a level in your design that knows how to recover from the failure or stop the entire program gracefully, which is where you catch the exception. I’ve never quite understood the idea that exceptions are similar to goto. Other than transferring control over potentially long “distances” within a program, they don’t seem to have much in common at all. To me, a much closer analogy would be returning early from a function on success, if you reach a point in your algorithm where you already know the required answer to whatever question your calling code was asking. Another similar situation would be using a break or continue statement to finish an iteration early within a loop, or adding extra guard cases to stop a recursion early, again if you already know the outcome and continuing with the full algorithm has no advantage.
  - evincarofautumn 10y ago
    > I can’t help noticing that much of your objection applies just as much to return as to throw. Isn’t the point, in both cases, that you shouldn’t need to reason about where you’ll end up? That is the point, but my specific objection is to the dynamic binding and dynamic typing, not the returning. With “return”, even early return, you don’t really need to reason about where you’ll end up at all—it’s always the end of the current function. And the same goes for functions that throw exceptions directly. The problem is that when you have unchecked exceptions, any function can throw, so every function call in your code is now also a potential early return, and for correct code you need to account for that.
  - pjc50 10y ago
    The real failure is that return types must be declared by exceptions need not be and generally aren't. So an exception can come teleporting through any part of your code. You can no longer enforce single return style, because any expression can return. This means that writing state-modifying code becomes unreasonably difficult, as you can no longer just write: // A and B must be kept in sync and updated together A = computeA() B = computeB() .. because it's possible that computeB() throws an exception, leaving the two out of sync. Yes, there are ways round this involving temporary variables. So you write: tmpA = computeA() tmpB = computeB() A = tmpA, B = tmpB; and home that neither an optimiser nor an intern removes the tmp variables. But wait! This still doesn't work, because your evil coworker has defined operator= on B to throw an exception! Personally I don't think that exceptions work very well in the presence of mutable state. Without mutable state, they're exactly equivalent to
pjmlp 10y ago
It is very hard to make libraries that rely on features that can be turned off. The bad idea was making language features optional. Library writers are forced to either support all possible combinations, don't use any of them or use them and see their library being rejected by those that won't turn on the features even at point gun. One of the things that made me initially enjoy Java was that there weren't features to turn on or off.
- adamnemecek 10y ago
  You are correct but all those books on cpp exceptions are about a bit more than dealing with issues related to optionally disabling them :-).
  - pjmlp 10y ago
    Agree, but that is because when compared with other languages exceptions in C++ were always bolted on. They don't play well with manual memory management or the C semantics C++ was trying to be as compatible as possible. They don't play well with: - constructors/destructors - manual resource management - low level code like UNIX signals - allowing every possible type to be used as exception So all of that made C++ exceptions poor cousins of how exceptions are used in other languages. I have used exceptions in quite a few languages and rather use them (the alternative being sum types), but do understand that how C++ evolved they are an unwelcome feature.
    - quotemstr 10y ago
      It's only exceptions that allow constructors to work properly and that allow the language to support value type management. Without exceptions, you need two-phase initialization, and that's a nightmare.
      - pjmlp 10y ago
        I hate two-phase initialization with passion, specially the way it was done in Symbian C++.
zvrba 10y ago
You're funny. gotos are used to emulate cleanup both of which you get in a more structured manner with RAII and exceptions. Rmember Apple's infamous "goto bug" in OpenSSL?
- adamnemecek 10y ago
  I'm well aware. I was talking about old school gotos, I should have probably said that.
- Peaker 10y ago
  While RAII and exceptions are better than goto's, the "goto fail" bug is not an example of that. The problem there was mismatch between indentation and parse which was a result of brace-less style and whitespace-insensitivity.
cyphar 10y ago
Except gotos are legitimately useful for cleanup inside a function before you return an error (see: the Linux kernel). Exceptions have overhead, and you have no idea where it will end up because the exception will bubble up the current call-stack, while gotos are local to the current function (and while longjmp is a mess, it is useful if you use clone(2)).
- adamnemecek 10y ago
  I'm well aware. I was talking about old school gotos, I should have probably said that.
- vvanders 10y ago
  You should be using RAII for any resources that you need to automatically clean up, then any return statement will catch it. No need for exceptions.
  - cyphar 10y ago
    RAII is not a feature of C. I was commenting on how gotos are not like exceptions, because gotos are actually useful and don't cause your program to make less sense as a result.
IshKebab 10y ago
Yeah finally. The problem with exceptions is that you lose context about where the error occurred, and you really need to know that to handle the error properly. That's why most exception handlers just print the error. I think the only situation where exceptions help is in constructors, but there are better solutions to that problem, like explicit object construction methods that can return an error. I think Go's approach to error handling is the best - explicit and in context. Rust's `Result` looks quite nice though I haven' tried it yet.
- barrkel 10y ago
  Most errors shouldn't be handled; that's the reason most exception handlers simply log the error. I've said it here before, but this is my classification of errors that exceptions are commonly used for: 1) Programming error: null pointer exception, library invariants broken, etc. These generally shouldn't be caught, and could arguably be replaced by fatal assertions, but that's typically not a polite thing to do in a library. 2) Non-deterministic failure condition: something outside the control of the calling code failed in a way that it cannot predict ahead of time. A network connection broke, a file was deleted unexpectedly, a device was detached, database server died, etc. There's something of an argument for annotating functions that can fail this way in the manner of Java's checked exceptions and it has a strong relationship with the IO monad in Haskell (and similar problems with encapsulation and hiding implementation details). These kinds of errors can sometimes be handled, and handling them with exceptions isn't much better or worse than error codes. An advantage of exceptions is that they makes it easy to abort the whole task and go back to the request handler (server code) or event dispatch loop (UI code). Exceptions can carry more state than error codes, too. 3) Business logic problem: the user, for want of a better term, of the program tried to do something that is not allowed / possible, and the program needs to abort the current task and inform the user of the problem. Exceptions are as good a means of aborting as most others. These should only be caught at the top level, whereupon they can be converted into something for human / 422 response / whatever consumption. In almost all cases, you cannot proceed and there is nothing you can do in reaction to the error. Aborting and unwinding the call stack is usually the correct thing to do.
- clappski 10y ago
pif 10y ago
When used for exceptional things, exceptions are wonderful. But they were never meant to completely replace status-related exit codes. Expected errors (ex: log file does not exist, so create a new one) are not to be treated via exceptions; exceptional errors (ex: no more memory available, and I'm just trying to allocate a few bytes) are.
protomyth 10y ago
I can see it in C++, but they seemed to work pretty well in Ada. A lot of things seem to work better in Ada to be truthful.

hacker_9 10y ago

This is actually really interesting to me. I use C# for side projects and often write Debug.Assert everywhere to check things, but can't quite bring myself to throw exceptions for full blown errors. I just find they add a lot of bloat, and don't really help the problem, they are just a lazy catch all. But I have to say returning Error<TResult> is a really elegant way of dealing with the problem, I think I will have to start doing it this way.

barrkel 10y ago
Returning an error type, and, in the caller, propagating that return type further up, is isomorphic to exceptions, except it's a lot more busywork, a lot more code bloat, and a lot easier to get wrong.
- perspectivep 10y ago
  And you have to remember to log the error at every level of the stack, otherwise you're left with an error code that has no context.
- yoklov 10y ago
  It's also encoded in the return type of the function, so you get static type checking -- a property not present for exceptions.
  - barrkel 10y ago
    You say that like it's desirable. I think Java's experience of checked exceptions shows that it's of very dubious benefit.

quotemstr 10y ago

C++ projects banning exceptions is a massive blunder. We should not disable important aspects of the language that provide useful semantic features to satisfy the anti-bloat superstitions of a few who remember bad C++ compilers of the 1990s. Nobody feels the need to create an exception-less variant of Java or Python, after all. A ban on C++ exceptions is a huge red flag for me. A project has to be really special if I'm going to contribute to it after it's crippled the language.

bigcheesegs 10y ago
The llvm-project is a compiler. Its developers are well aware of the true cost of exceptions.
- barrkel 10y ago
  Actually, compilers typically don't use exceptions because they don't usually abort on the first instance of a problem. Compilation has historically been an lengthy batch job, and thus reporting many errors to be fixed between iterations improves user productivity.
  - favorited 10y ago
    I think the point was that LLVM compiler infrastructure has a first-class C++ font-end. They know the ins-and-outs of language features because they are implementing standards-compliant compilers for said language.
    - barrkel 10y ago
      Most self-hosted compilers are written in languages ill-suited to compiler writing. The choice of features used is often a compromise, rather than best practice for either good compiler design or good target language use. C++ users in particular have strong concerns about things like RTTI and the overhead of exceptions not thrown. The cost of making unthrown exceptions low (near zero) is that throwing exceptions is much more expensive. This turns into a feedback loop, where C++ programs end up performing better if they never throw any exceptions because of the tradeoff. This feeds into self-hosted compilers. Thing is, certain compiler design techniques can work well with cheap unwinding: constraint solving (more common in languages with better type systems than C++), forward-looking grammar assertions with speculative parsing, IDE-integrated code completion (implement the lexer to add the cursor position as a special token, and jump out of the parser when it's found, where all the context is available to pass along). But C++'s peculiar tradeoffs may make using things like exceptions less than ideal to use for this purpose, not because exceptions are the wrong tool, but because most C++ programs are not compilers and aren't tuned for it. And OTOH, compilers written in low-level languages like C++ often twist themselves into knots to simulate things like tree pattern matching, multiple dispatch, destructuring binds, etc. Sometimes they even give up and write code generating tools.