5 ms·

An interesting point raised by this paper is that when a program requires pervasive modifications (e.g. checking the error code returned by C functions), adding

An interesting point raised by this paper is that when a program requires pervasive modifications (e.g. checking the error code returned by C functions), adding a new concept to the language (e.g. C++ exceptions) can systematically make these changes unnecessary, therefore simplifying the program. Perhaps this is how programming language designers ought to vet language ideas: do the proposed changes make certain patterns redundant? Looking at Rust through this lens makes it clear that it aims to eliminate C-style manual memory management. However, it does make me wonder: How do languages such as JavaScript and Python stand out from their predecessors, and what problems do they uniquely solve?

jstimpfle 8y ago
> exceptions > simplifying Erm, no. Some consequences: non-obvious control flow, RAII, constructors, move semantics, exception safety, efficiency, stack unwinding... A better way to deal with the "problem" of unchecked error codes is to have the compiler check that something happens to the result value. This is what Chandler Carruth suggests. An even better (but orthogonal) way is to structure the code so it does only one thing at a time, and does any one thing only in one place (ideally).
- beaconstudios 8y ago
  compared to error codes, exceptions are simpler IMO. Many issues with exceptions come from using them in non-exceptional circumstances, i.e. for control flow.
  - jstimpfle 8y ago
    Look up the definition of "simple". How exactly do you distinguish "exceptional" from "non-exceptional"?
    - beaconstudios 8y ago
      > Look up the definition of "simple". There's no need to be dismissive. I refer to simple as simple to use, not simple to conceptualise. I would say exceptional is a situation that is rare and unexpected. When saving a record to a table with a unique constraint, I would expect the constraint to prevent saving but I would not usually attempt to handle/recover the app running out of memory. So it's situational and I'd say the distinction is between whether you will be explicitly handling the event as part of normal behaviour. The more stable the app needs to be, the more situations need to be handled.
      - jstimpfle 8y ago
        I agree and I think the conclusion is that it's up to the caller to decide what is exceptional. But unfortunately it's the callee who decides how the result is returned. And it's not only the caller, but also the caller of the caller, and so on, who needs to be prepared for exceptions. This all has severe ramifications on the code structure. > There's no need to be dismissive. I refer to simple as simple to use, not simple to conceptualise. Sorry. I need to control myself. It's not about you. As another commenter stated there is an agreed upon distinction between simple and easy. The distinction is important especially among programmers, and what you described might be easy but it's not simple.
        beaconstudios 8y ago
        agreed, there are better ways to handle such circumstances (such as an Either/Validation monad). But I still think exceptions are better than error codes. If you don't handle an error code, you can proceed through your application in an invalid state. If you don't handle an exception, the application crashes out. I think the latter is preferable in most circumstances.
        jstimpfle 8y ago
        Yes, and this is the reason why I'm happy with exceptions for short scripts, e.g. Python. It's a different story for larger projects where I make all the primitives by myself. There I start by explicitly aborting on cases that are not handled yet (no exceptions needed to do that), and then I gradually change the structure of the code to handle more and more "exceptional" cases.
    - gwright 8y ago
      The best description of exceptions that I've seen is Bertrand Meyer's exposition of them in _Object Oriented Software Construction_. His definition depends on the notion of Design by Contract. An exception is an event that causes a function/method to fail because it is unable to satisfy its contract. The caller is then responsible for cleaning things up (so it can satisfy its contract) or it also triggers an exception resulting it its failure. In the context of Design by Contract, the list of things that can cause an exception include: * hardware/OS errors * calling a method on a null reference * calling a method that itself fails * discovering a pre-condition isn't true * discovering that a post-condition isn't true * discovering that a class-invariant isn't true * loop invariant failure or lack of progress * assertion failures * explicit triggering of an exception I highly recommend Object Oriented Software Construction.
      - jstimpfle 8y ago
        I think this is a hair-splitting distinction and it does not work reliably. Sorry. Things that truly "cannot" happen => you do not know how to recover => you terminate the program. That's it.
        gwright 8y ago
        That is why the definition is recursive. If every failure triggers a new exception all the way up the call stack, then your program fails.
        jstimpfle 8y ago
        Yeah, so what was the point to begin with?
        gwright 8y ago
        Do you understand Design By Contract? That is the theory that provides the distinction between a function/method finishing with success or with failure. The notion of contract is what distinguishes an exception from a glorified GOTO.
  - kungtotte 8y ago
    Don't mix up simple and easy, they are orthogonal concepts. Exceptions are in no way simpler than C-style error codes, but in many cases they might be easier to work with.
    - beaconstudios 8y ago
      simple to use versus simple to understand. I was referring to the former.
  - woadwarrior01 8y ago
    Case in point: Python’s StopIteration exception, which is raised to indicate iterator exhaustion. A lot of efficiency can be gained by not invoking Python’s heavy exception handling machinery for this.
- tiniuclx 8y ago
  You do have a point, adding exceptions to C++ does impact the language in many ways. They must be used responsibly: being able to jump to a completely different point of the program at any time is dangerous. However, exceptions do simplify some situations, such as when an unrecoverable error happens at the bottom of a deep call stack. Exceptions make it simple to inform the user/system that an error has occurred without adding error checks to every function in the call stack. I believe this use-case justifies the feature, especially if you can tolerate the performance loss which might not even be that bad [0]. Having the compiler check error codes is one of the reasons I enjoy Haskell so much: the type system makes you handle failure (amongst other things). [0] http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf - Section 5.4.1.2 - the table approach to exception handling has no run-time cost during normal (non-exceptional) program flow.
  - jstimpfle 8y ago
    The efficiency problem need not be the exception handling in itself (I can't say a lot about that. There are various claims and it probably depends on the tradeoffs of the language implementation). The actual problem is the ramifications on the code structure. A deep call stack with a lot of implicit context is a problem in itself. Exceptions imply a temporal coupling from error occurrence to error handling. This is a subtle but severe problem. It might start out as a noticeable maintainability problem but it's likely to quickly become a performance problem as well...
    - uryga 8y ago
      > Exceptions imply a temporal coupling from error occurrence to error handling. Could you expand on this? I understood your statement as "Exceptions sort-of force you to handle an error the moment it occurs", but I'm having trouble seeing why this would be specific to exceptions and not the case with other error handling solutions. (I don't mean to sound like a big exception-defender – I prefer ML/Rust-style Result types)
      - gbear605 8y ago
AnimalMuppet 8y ago
I think it's also how you should pick languages for a project. What is the worst yak-shaving aspect of the code you're going to have to write for this particular project? What language will go the furthest toward making that yak shaving go away? Pick that language.
- pjmlp 8y ago
  I pick the languages based on the platform stack I have to use and not the other way around. Basically the first class languages on a given platform, or having official bindings for a specific set of libraries that must be used. My experience has proven it is the best path for lowest attrition. Every time I decided to do otherwise I repented later on.
pjc50 8y ago
The wikipedia summary of the JavaScript design rational is decent; it also kind of explains why it's so odd: > In 1995, Netscape Communications recruited Brendan Eich with the goal of embedding the Scheme programming language into its Netscape Navigator.[11] Before he could get started, Netscape Communications collaborated with Sun Microsystems to include in Netscape Navigator Sun's more static programming language Java, in order to compete with Microsoft for user adoption of Web technologies and platforms.[12] Netscape Communications then decided that the scripting language they wanted to create would complement Java and should have a similar syntax, which excluded adopting other languages such as Perl, Python, TCL, or Scheme. To defend the idea of JavaScript against competing proposals, the company needed a prototype. Eich wrote one in 10 days, in May 1995. It had to look vaguely like Java (hence ALGOL-derived brace delimited blocks rather than Scheme-derived prefix S-expressions, and the confusing name), and it had to be implemented quickly (hence the lack of typechecker and other advanced features), and it was intended to be beginner-friendly (hence all the truthiness/falsiness stuff). Javascript only succeeds because it's the only scripting language supported by web browsers, and the brief attempt at getting VBScript into browsers was even worse.
- pier25 8y ago
  > and it had to be implemented quickly (hence the lack of typechecker and other advanced features) Since then there has been more than enough time to implement optional static types. In fact, the EcmaScript 4 proposal had those, before it was trashed in 2007 or so and the TC39 started EcmaScript 5 from scratch.
  - tabtab 8y ago
    JavaScript is fine for the job of hooking light-duty events to HTML, but people try to write entire GUI/graphics engines in it. It's the wrong tool for that job, just as you don't write an OS in TCL. The whole Web UI "standards" issue needs a big overhaul in my opinion, but Web UI's is probably off topic. (I've ranted about it in other topics.)
- quineoa 8y ago
  This seems like an extreme case of “assume your hack will be used in production for years to come.”

jstimpfle 8y ago

> exceptions > simplifying Erm, no. Some consequences: non-obvious control flow, RAII, constructors, move semantics, exception safety, efficiency, stack unwinding... A better way to deal with the "problem" of unchecked error codes is to have the compiler check that something happens to the result value. This is what Chandler Carruth suggests. An even better (but orthogonal) way is to structure the code so it does only one thing at a time, and does any one thing only in one place (ideally).

beaconstudios 8y ago
compared to error codes, exceptions are simpler IMO. Many issues with exceptions come from using them in non-exceptional circumstances, i.e. for control flow.
- jstimpfle 8y ago
  Look up the definition of "simple". How exactly do you distinguish "exceptional" from "non-exceptional"?
  - beaconstudios 8y ago
    > Look up the definition of "simple". There's no need to be dismissive. I refer to simple as simple to use, not simple to conceptualise. I would say exceptional is a situation that is rare and unexpected. When saving a record to a table with a unique constraint, I would expect the constraint to prevent saving but I would not usually attempt to handle/recover the app running out of memory. So it's situational and I'd say the distinction is between whether you will be explicitly handling the event as part of normal behaviour. The more stable the app needs to be, the more situations need to be handled.
    - jstimpfle 8y ago
      I agree and I think the conclusion is that it's up to the caller to decide what is exceptional. But unfortunately it's the callee who decides how the result is returned. And it's not only the caller, but also the caller of the caller, and so on, who needs to be prepared for exceptions. This all has severe ramifications on the code structure. > There's no need to be dismissive. I refer to simple as simple to use, not simple to conceptualise. Sorry. I need to control myself. It's not about you. As another commenter stated there is an agreed upon distinction between simple and easy. The distinction is important especially among programmers, and what you described might be easy but it's not simple.
      - beaconstudios 8y ago
        agreed, there are better ways to handle such circumstances (such as an Either/Validation monad). But I still think exceptions are better than error codes. If you don't handle an error code, you can proceed through your application in an invalid state. If you don't handle an exception, the application crashes out. I think the latter is preferable in most circumstances.
        jstimpfle 8y ago
        Yes, and this is the reason why I'm happy with exceptions for short scripts, e.g. Python. It's a different story for larger projects where I make all the primitives by myself. There I start by explicitly aborting on cases that are not handled yet (no exceptions needed to do that), and then I gradually change the structure of the code to handle more and more "exceptional" cases.
  - gwright 8y ago
    The best description of exceptions that I've seen is Bertrand Meyer's exposition of them in _Object Oriented Software Construction_. His definition depends on the notion of Design by Contract. An exception is an event that causes a function/method to fail because it is unable to satisfy its contract. The caller is then responsible for cleaning things up (so it can satisfy its contract) or it also triggers an exception resulting it its failure. In the context of Design by Contract, the list of things that can cause an exception include: * hardware/OS errors * calling a method on a null reference * calling a method that itself fails * discovering a pre-condition isn't true * discovering that a post-condition isn't true * discovering that a class-invariant isn't true * loop invariant failure or lack of progress * assertion failures * explicit triggering of an exception I highly recommend Object Oriented Software Construction.
    - jstimpfle 8y ago
      I think this is a hair-splitting distinction and it does not work reliably. Sorry. Things that truly "cannot" happen => you do not know how to recover => you terminate the program. That's it.
      - gwright 8y ago
        That is why the definition is recursive. If every failure triggers a new exception all the way up the call stack, then your program fails.
        jstimpfle 8y ago
        Yeah, so what was the point to begin with?
        gwright 8y ago
        Do you understand Design By Contract? That is the theory that provides the distinction between a function/method finishing with success or with failure. The notion of contract is what distinguishes an exception from a glorified GOTO.
- kungtotte 8y ago
  Don't mix up simple and easy, they are orthogonal concepts. Exceptions are in no way simpler than C-style error codes, but in many cases they might be easier to work with.
  - beaconstudios 8y ago
    simple to use versus simple to understand. I was referring to the former.
- woadwarrior01 8y ago
  Case in point: Python’s StopIteration exception, which is raised to indicate iterator exhaustion. A lot of efficiency can be gained by not invoking Python’s heavy exception handling machinery for this.
tiniuclx 8y ago
You do have a point, adding exceptions to C++ does impact the language in many ways. They must be used responsibly: being able to jump to a completely different point of the program at any time is dangerous. However, exceptions do simplify some situations, such as when an unrecoverable error happens at the bottom of a deep call stack. Exceptions make it simple to inform the user/system that an error has occurred without adding error checks to every function in the call stack. I believe this use-case justifies the feature, especially if you can tolerate the performance loss which might not even be that bad [0]. Having the compiler check error codes is one of the reasons I enjoy Haskell so much: the type system makes you handle failure (amongst other things). [0] http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf - Section 5.4.1.2 - the table approach to exception handling has no run-time cost during normal (non-exceptional) program flow.
- jstimpfle 8y ago
  The efficiency problem need not be the exception handling in itself (I can't say a lot about that. There are various claims and it probably depends on the tradeoffs of the language implementation). The actual problem is the ramifications on the code structure. A deep call stack with a lot of implicit context is a problem in itself. Exceptions imply a temporal coupling from error occurrence to error handling. This is a subtle but severe problem. It might start out as a noticeable maintainability problem but it's likely to quickly become a performance problem as well...
  - uryga 8y ago
    > Exceptions imply a temporal coupling from error occurrence to error handling. Could you expand on this? I understood your statement as "Exceptions sort-of force you to handle an error the moment it occurs", but I'm having trouble seeing why this would be specific to exceptions and not the case with other error handling solutions. (I don't mean to sound like a big exception-defender – I prefer ML/Rust-style Result types)
    - gbear605 8y ago

AnimalMuppet 8y ago

I think it's also how you should pick languages for a project. What is the worst yak-shaving aspect of the code you're going to have to write for this particular project? What language will go the furthest toward making that yak shaving go away? Pick that language.

pjmlp 8y ago
I pick the languages based on the platform stack I have to use and not the other way around. Basically the first class languages on a given platform, or having official bindings for a specific set of libraries that must be used. My experience has proven it is the best path for lowest attrition. Every time I decided to do otherwise I repented later on.

pjc50 8y ago

The wikipedia summary of the JavaScript design rational is decent; it also kind of explains why it's so odd: > In 1995, Netscape Communications recruited Brendan Eich with the goal of embedding the Scheme programming language into its Netscape Navigator.[11] Before he could get started, Netscape Communications collaborated with Sun Microsystems to include in Netscape Navigator Sun's more static programming language Java, in order to compete with Microsoft for user adoption of Web technologies and platforms.[12] Netscape Communications then decided that the scripting language they wanted to create would complement Java and should have a similar syntax, which excluded adopting other languages such as Perl, Python, TCL, or Scheme. To defend the idea of JavaScript against competing proposals, the company needed a prototype. Eich wrote one in 10 days, in May 1995. It had to look vaguely like Java (hence ALGOL-derived brace delimited blocks rather than Scheme-derived prefix S-expressions, and the confusing name), and it had to be implemented quickly (hence the lack of typechecker and other advanced features), and it was intended to be beginner-friendly (hence all the truthiness/falsiness stuff). Javascript only succeeds because it's the only scripting language supported by web browsers, and the brief attempt at getting VBScript into browsers was even worse.

pier25 8y ago
> and it had to be implemented quickly (hence the lack of typechecker and other advanced features) Since then there has been more than enough time to implement optional static types. In fact, the EcmaScript 4 proposal had those, before it was trashed in 2007 or so and the TC39 started EcmaScript 5 from scratch.
- tabtab 8y ago
  JavaScript is fine for the job of hooking light-duty events to HTML, but people try to write entire GUI/graphics engines in it. It's the wrong tool for that job, just as you don't write an OS in TCL. The whole Web UI "standards" issue needs a big overhaul in my opinion, but Web UI's is probably off topic. (I've ranted about it in other topics.)
quineoa 8y ago
This seems like an extreme case of “assume your hack will be used in production for years to come.”