4 ms·

This feels like an ergonomic improvement to Java's checked/unchecked exceptions.

by Bjartr 2y ago

kelnos 2y ago
After many many years I've come to the conclusion that languages that use exceptions for error handling should only have checked exceptions. As much as I have railed on Java's checked exceptions in the past, I think unchecked exceptions give you either brittle code, or unreadable code littered with gratuitous try/catch because you never know what might or might not throw. And I don't think this would actually be that bad. Functions/methods could still decide not to propagate exceptions outward; they just have to declare what they throw/propagate. Of course, the problem here is that the list of thrown exceptions becomes a part of a function's API (and possibly ABI); changing the implementation details of a function -- even without changing its behavior -- might require you to add a new exception to the list, which would be an API break. I expect this would lead people to often declare that their functions throw the generic base-class Exception type, which isn't great.
- wvenable 2y ago
  Functions should not be exposing their implementation and that's what makes something an error rather than just output from a function. One should not care if a function was implemented as a pure calculation, read from a file on disk, or use a network service. And that should be able to change at anytime without breaking the callers. This means that checked exceptions and explicit error returns that are anything other than a very generic error type are incompatible with encapsulation and polymorphism. I think the best generic solution to error handling is unchecked exceptions. Most code should not be littered with try/catch blocks and none of them should be gratuitous. Even in my largest projects the number of catch blocks can be counted on one or two hands. You don't need to know what might or might not throw -- everything can throw. If something does throw today, it could throw tomorrow. Don't worry about that. With unchecked exceptions, just concern yourself on what you can handle and where you can handle it. Most error handling is either to abort (the operation or application) or retry.
  - layer8 2y ago
    It is often important for the caller to know under what circumstances and for what reasons a function can fail, in order to react appropriately. In particular, callers want to distinguish between expected and unexpected errors, which can differ from use case to use case, and for expected errors they may want to distinguish between different expected cases, for example to decide whether it makes sense to retry the operation or not. This doesn’t mean that the function signature has to expose implementation details. If the function is file_open(), listing FileNotFound as one of the possible errors doesn’t expose an implementation detail. If the function is sql_insert(), distinguishing between ConnectionError and UniqueKeyConflict is useful and doesn’t expose implementation details. Different error modes like that exist on all levels of an application.
    - wvenable 2y ago
      A function containing file_open() or sql_insert() will expose implementation details if it leaks those errors out. I don't disagree but most of my application is not in those leaves; it's a call stack 20 levels deep.
      - layer8 2y ago
        > A function containing file_open() or sql_insert() will expose implementation details if it leaks those errors out. The correct thing to do in that case is to wrap/convert those errors to errors that are appropriate to that function’s interface contract. Exception types are an important part of a function signature, and should be designed accordingly, not be propagated blindly. With unchecked exceptions, you are leaking implementation details dynamically, and you don’t even know it/can’t control it, because they are not statically checked. If you care about leaking implementation details, unchecked exceptions are arguably worse. > I don't disagree but most of my application is not in those leaves; it's a call stack 20 levels deep. I regularly have such failure mode distinctions in higher-level program logic as well. With unchecked exceptions, you often aren’t even aware what failure modes you have.
        2y ago
- layer8 2y ago
  Unchecked exceptions make sense for precondition checks and the like, that is, to signal bugs in the application. Otherwise I agree, checked exceptions are the way.
- AtlasBarfed 2y ago
  Alas the java community disagrees, and this collective decision should be carefully analyzed and respected Because it represents the conclusion, despite ample guidance and dogma by Sun, of the mass market millions of java programmers, resulting in second generation (groovy) and third generation (kotlin) JVM languages that dropped checked exceptions entirely. It might be the languages error handling syntax (try catch) led to ugly code (and I always contended that local vars declared in a try block should have been lexically visible to catch blocks) It might be that javas std lib had a poorly designed exception pattern. It could be that implementing exception classes was annoying. But I think there is other reasons. In large scale enterprise development, checked exceptions start to pollute and permeate code that otherwise doesn't want excessive type system exposure from the linked /imported libraries. What results even with checked exception lite is that "exception barriers" that catch all exceptions and repackage them are established at major system boundaries. Checked exception enforcement would just create more of these IMO. The wet dream of checked exceptions was encouraging APIs that had a thorough understanding of all the error conditions and could use checked exceptions to enforce a good handling recovery API usage pattern In reality it's the halting problem: too hard to predict l all the error conditions (that isn't really known until version 3 or 4 of the API and by then the API signatures are set. Let's look at something simple like json serialization. Yeah there's a litany of parse errors and the like. But there is ALSO the issue of disparate sources of the json. File errors from file sources. Network errors from streamed communication channels. Your general stream or file interface isn't that simple of an abstraction when source specific errors raise their heads. The abstraction become leaky real real fast.
  - Yeroc 2y ago
    I'm one of the naysayers as an experienced Java developer that supports checked exceptions. I find the move to runtime exceptions very disheartening though I will say that in a world dominated by web applications with a clear request/response cycle it's very easy for the container/application to implement a high-level error-handler so I think this skews people's sense of the value proposition of checked exceptions. I've done a fair bit of work over the years writing daemons of various types and having checked IO exceptions among others has been a lifesaver. I also feel that vilifying use of generic exceptions (IOException, SQLException) in favour of implementation-specific exceptions was a mistake. If instead, we had encouraged a smaller set of mostly platform-defined exceptions I believe people would have found the exception "noise" to be lesser. While there are cases where a custom exception sub-type can be useful, in many cases they are not. I agree with the grandparent comment that we may have been better off without runtime exceptions at all, leaving us with simply checked exceptions and errors.

This feels like an ergonomic improvement to Java's checked/unchecked exceptions.

by Bjartr 2y ago

This feels like an ergonomic improvement to Java's checked/unchecked exceptions.

After many many years I've come to the conclusion that languages that use exceptions for error handling should only have checked exceptions. As much as I have railed on Java's checked exceptions in the past, I think unchecked exceptions give you either brittle code, or unreadable code littered with gratuitous try/catch because you never know what might or might not throw. And I don't think this would actually be that bad. Functions/methods could still decide not to propagate exceptions outward; they just have to declare what they throw/propagate. Of course, the problem here is that the list of thrown exceptions becomes a part of a function's API (and possibly ABI); changing the implementation details of a function -- even without changing its behavior -- might require you to add a new exception to the list, which would be an API break. I expect this would lead people to often declare that their functions throw the generic base-class Exception type, which isn't great.

wvenable 2y ago
Functions should not be exposing their implementation and that's what makes something an error rather than just output from a function. One should not care if a function was implemented as a pure calculation, read from a file on disk, or use a network service. And that should be able to change at anytime without breaking the callers. This means that checked exceptions and explicit error returns that are anything other than a very generic error type are incompatible with encapsulation and polymorphism. I think the best generic solution to error handling is unchecked exceptions. Most code should not be littered with try/catch blocks and none of them should be gratuitous. Even in my largest projects the number of catch blocks can be counted on one or two hands. You don't need to know what might or might not throw -- everything can throw. If something does throw today, it could throw tomorrow. Don't worry about that. With unchecked exceptions, just concern yourself on what you can handle and where you can handle it. Most error handling is either to abort (the operation or application) or retry.
- layer8 2y ago
  It is often important for the caller to know under what circumstances and for what reasons a function can fail, in order to react appropriately. In particular, callers want to distinguish between expected and unexpected errors, which can differ from use case to use case, and for expected errors they may want to distinguish between different expected cases, for example to decide whether it makes sense to retry the operation or not. This doesn’t mean that the function signature has to expose implementation details. If the function is file_open(), listing FileNotFound as one of the possible errors doesn’t expose an implementation detail. If the function is sql_insert(), distinguishing between ConnectionError and UniqueKeyConflict is useful and doesn’t expose implementation details. Different error modes like that exist on all levels of an application.
  - wvenable 2y ago
    A function containing file_open() or sql_insert() will expose implementation details if it leaks those errors out. I don't disagree but most of my application is not in those leaves; it's a call stack 20 levels deep.
    - layer8 2y ago
      > A function containing file_open() or sql_insert() will expose implementation details if it leaks those errors out. The correct thing to do in that case is to wrap/convert those errors to errors that are appropriate to that function’s interface contract. Exception types are an important part of a function signature, and should be designed accordingly, not be propagated blindly. With unchecked exceptions, you are leaking implementation details dynamically, and you don’t even know it/can’t control it, because they are not statically checked. If you care about leaking implementation details, unchecked exceptions are arguably worse. > I don't disagree but most of my application is not in those leaves; it's a call stack 20 levels deep. I regularly have such failure mode distinctions in higher-level program logic as well. With unchecked exceptions, you often aren’t even aware what failure modes you have.
      - 2y ago
layer8 2y ago
Unchecked exceptions make sense for precondition checks and the like, that is, to signal bugs in the application. Otherwise I agree, checked exceptions are the way.
AtlasBarfed 2y ago
Alas the java community disagrees, and this collective decision should be carefully analyzed and respected Because it represents the conclusion, despite ample guidance and dogma by Sun, of the mass market millions of java programmers, resulting in second generation (groovy) and third generation (kotlin) JVM languages that dropped checked exceptions entirely. It might be the languages error handling syntax (try catch) led to ugly code (and I always contended that local vars declared in a try block should have been lexically visible to catch blocks) It might be that javas std lib had a poorly designed exception pattern. It could be that implementing exception classes was annoying. But I think there is other reasons. In large scale enterprise development, checked exceptions start to pollute and permeate code that otherwise doesn't want excessive type system exposure from the linked /imported libraries. What results even with checked exception lite is that "exception barriers" that catch all exceptions and repackage them are established at major system boundaries. Checked exception enforcement would just create more of these IMO. The wet dream of checked exceptions was encouraging APIs that had a thorough understanding of all the error conditions and could use checked exceptions to enforce a good handling recovery API usage pattern In reality it's the halting problem: too hard to predict l all the error conditions (that isn't really known until version 3 or 4 of the API and by then the API signatures are set. Let's look at something simple like json serialization. Yeah there's a litany of parse errors and the like. But there is ALSO the issue of disparate sources of the json. File errors from file sources. Network errors from streamed communication channels. Your general stream or file interface isn't that simple of an abstraction when source specific errors raise their heads. The abstraction become leaky real real fast.
- Yeroc 2y ago
  I'm one of the naysayers as an experienced Java developer that supports checked exceptions. I find the move to runtime exceptions very disheartening though I will say that in a world dominated by web applications with a clear request/response cycle it's very easy for the container/application to implement a high-level error-handler so I think this skews people's sense of the value proposition of checked exceptions. I've done a fair bit of work over the years writing daemons of various types and having checked IO exceptions among others has been a lifesaver. I also feel that vilifying use of generic exceptions (IOException, SQLException) in favour of implementation-specific exceptions was a mistake. If instead, we had encouraged a smaller set of mostly platform-defined exceptions I believe people would have found the exception "noise" to be lesser. While there are cases where a custom exception sub-type can be useful, in many cases they are not. I agree with the grandparent comment that we may have been better off without runtime exceptions at all, leaving us with simply checked exceptions and errors.