6 ms·

> It's not really about Java giving exceptions a bad rap. After all exceptions are a feature of almost any OOP language designed after 1990 and they work nearly

> It's not really about Java giving exceptions a bad rap. After all exceptions are a feature of almost any OOP language designed after 1990 and they work nearly the same way in all of them. Java has checked exceptions which have been universally agreed upon as bad idea. No subsequent languages use them and they've even been removed from C++. Unfortunately most common first programmers' language is Java and they learn the worst possible implementation of exceptions. All your pro-exception arguments (and all mine) pretty much all apart when dealing with checked exceptions. So it's easy to see why anyone who's only exposure to exceptions was from Java would consider error returns the superior option. > But implementing this well is hard, because generating a good stack trace in the presence of optimised code with heavy use of inlining requires complex deoptimisation metadata and many table lookups to convert the optimised stack back into something the programmer will recognise. Of course, the only reason any of this is necessary is because compilers don't implement exceptions in naive way of simply returning and propagating the exception the same way you would propagate an error return. Instead they go through a convoluted mess to ensure that in the case the exception doesn't occur, you pay no run-time performance penalty. So, in fact, this is still an advantage of exceptions over error returns. This is merely an optimization that is possible when error handling is not explicit.

mike_hearn 8y ago
That's all true. I've become more sympathetic to checked exceptions over time though. I think the issues Java had with it are more to do with poor choice of what to make checked in the standard library. For example IOException should not have been made checked. Also, it's too difficult to change an exception from checked to unchecked, and it should have created suppressable warnings rather than compiler errors. It's a pattern - early versions of Java erred too much in favour of making things compile errors rather than warnings, like unreachable code being an error , even though it's common whilst debugging or writing code (Go made the same mistake). Not catching checked exceptions is something very common whilst making prototype code or simple command line tools where all you can do with most errors is print the message and quit anyway. It isn't worth forcing the developer's hand via an error. But I won't be surprised to see some variant of checked exceptions be explored again in the coming years, probably with IDE support. Being able to know how a method can fail in the type system, beyond just checking the docs, is a very useful thing if the information is used in a reasonable way.
- wvenable 8y ago
  Checked exceptions fundamentally violate most of the principles of object-oriented programming by forcing you to expose implementation details into the method type signature. Encapsulation, abstraction, and even polymorphism are violated by this. Java programmers typically get around this by creating ClassNameException classes and then stuff the real exception (untyped) into the innerException property. Checked exceptions are conceptually and fundamentally flawed.
  - dragonwriter 8y ago
    > Checked exceptions fundamentally violate most of the principles of object-oriented programming by forcing you to expose implementation details into the method type signature No, they don't. They can be abused in a way which does this (and can be implemented in a way which unnecessarily creates avenues for it), but checked exceptions in general are isomorphic to static return types, and don't violate OOP any more than static return types do.
    - wvenable 8y ago
      Static return types would violated OOP as well if they exposed implementation details unrelated to the result of the operation. If you have a method called GetPrice() that uses a database, you know it, because you have to expose all the possible exceptions. If you change that to use a file or a network service, you have to change every caller and every caller of that. Is that abstraction? No. Is it polymorphism, also no. You can't have two different implementations of GetPrice() that are compatible unless they have exactly the same exception result. What's the value of that?
      - dragonwriter 8y ago
        > Static return types would violated OOP as well if they exposed implementation details unrelated to the result of the operation. Sure, but neither checked exceptions nor static return types inherently do that. Bad practices around either can, and bad language design around either can make that more likely. (I honestly think unchecked exceptions are a bigger problem, because they make poor chocies less obvious.) > If you have a method called GetPrice() that uses a database, you know it, because you have to expose all the possible exceptions. Only if you are letting them bubbled up as is; you only have to expose exceptions you don't handle, which is equivalent to if you shouldn't expose an exception to a caller, you must handle it, perhaps with a handler which simply throws an exception that is appropriate to expose.

mike_hearn 8y ago

That's all true. I've become more sympathetic to checked exceptions over time though. I think the issues Java had with it are more to do with poor choice of what to make checked in the standard library. For example IOException should not have been made checked. Also, it's too difficult to change an exception from checked to unchecked, and it should have created suppressable warnings rather than compiler errors. It's a pattern - early versions of Java erred too much in favour of making things compile errors rather than warnings, like unreachable code being an error , even though it's common whilst debugging or writing code (Go made the same mistake). Not catching checked exceptions is something very common whilst making prototype code or simple command line tools where all you can do with most errors is print the message and quit anyway. It isn't worth forcing the developer's hand via an error. But I won't be surprised to see some variant of checked exceptions be explored again in the coming years, probably with IDE support. Being able to know how a method can fail in the type system, beyond just checking the docs, is a very useful thing if the information is used in a reasonable way.

wvenable 8y ago
Checked exceptions fundamentally violate most of the principles of object-oriented programming by forcing you to expose implementation details into the method type signature. Encapsulation, abstraction, and even polymorphism are violated by this. Java programmers typically get around this by creating ClassNameException classes and then stuff the real exception (untyped) into the innerException property. Checked exceptions are conceptually and fundamentally flawed.
- dragonwriter 8y ago
  > Checked exceptions fundamentally violate most of the principles of object-oriented programming by forcing you to expose implementation details into the method type signature No, they don't. They can be abused in a way which does this (and can be implemented in a way which unnecessarily creates avenues for it), but checked exceptions in general are isomorphic to static return types, and don't violate OOP any more than static return types do.
  - wvenable 8y ago
    Static return types would violated OOP as well if they exposed implementation details unrelated to the result of the operation. If you have a method called GetPrice() that uses a database, you know it, because you have to expose all the possible exceptions. If you change that to use a file or a network service, you have to change every caller and every caller of that. Is that abstraction? No. Is it polymorphism, also no. You can't have two different implementations of GetPrice() that are compatible unless they have exactly the same exception result. What's the value of that?
    - dragonwriter 8y ago
      > Static return types would violated OOP as well if they exposed implementation details unrelated to the result of the operation. Sure, but neither checked exceptions nor static return types inherently do that. Bad practices around either can, and bad language design around either can make that more likely. (I honestly think unchecked exceptions are a bigger problem, because they make poor chocies less obvious.) > If you have a method called GetPrice() that uses a database, you know it, because you have to expose all the possible exceptions. Only if you are letting them bubbled up as is; you only have to expose exceptions you don't handle, which is equivalent to if you shouldn't expose an exception to a caller, you must handle it, perhaps with a handler which simply throws an exception that is appropriate to expose.