3 ms·

This [1] article by Raymond Chen is one of my favorite on exceptions. I admit there is an elegance to exceptions, but when I'm trying to write reliable code, I

This [1] article by Raymond Chen is one of my favorite on exceptions. I admit there is an elegance to exceptions, but when I'm trying to write reliable code, I find reasoning about exceptions significantly increases my cognitive load. Error handling is a place where a little more verbosity is okay because it keeps my focus on the local context rather than having to consider the entire call stack. I basically agree with the TL;DR of the article: "My point is that exceptions are too hard and I'm not smart enough to handle them". [1] https://blogs.msdn.microsoft.com/oldnewthing/20050114-00/?p=36693 https://blogs.msdn.microsoft.com/oldnewthing/20050114-00/?p=...

erikpukinskis 8y ago
This kind of thinking has permeated my coding practice. I used to think "this is hard, I need to learn about more systems until I'm smart enough to do this." Now I think "this is hard, there's probably something wrong with the architecture. I'll fix it."
wvenable 8y ago
That's the mistake with exceptions; if you assume every method can throw any kind of exception it actually reduces your cognitive load. Now you just have to worry about what you can handle in the 2 or 3 places in your code you can actually handle exceptions. Instead of infinite number of places an error can occur and the huge number of possible errors. The idea that error states are perfectly knowable everywhere in the code is a myth. Even if that were possible at one moment, the instant anyone changes code anywhere it will immediately be wrong.
- lazulicurio 8y ago
  > Now you just have to worry about what you can handle in the 2 or 3 places in your code you can actually handle exceptions This is only true if your application has no state or invariants that could possibly be invalidated in the face of exceptions. For instance, what would be your solution to the 'NotifyIcon' example given in the linked article? > The idea that error states are perfectly knowable everywhere in the code is a myth. Even if that were possible at one moment, the instant anyone changes code anywhere it will immediately be wrong This applies equally to both error codes and exceptions. If a method N layers down in your call stack changes its behavior, that's a potential breaking change regardless of your choice of error handling.
  - wvenable 8y ago
    > For instance, what would be your solution to the 'NotifyIcon' example given in the linked article? The notify icon code is poorly structured to begin with. Simply creating a NotifyIcon object adds it to the UI? That's an awful design. If there was an add to UI step then it would be a non-issue; the half-constructed NotifyIcon object would never get added to the UI. This issue is not magically resolved by having to explicitly handle every error; you can make the same mistake with twice as much code. > This applies equally to both error codes and exceptions. If a method N layers down in your call stack changes its behavior, that's a potential breaking change regardless of your choice of error handling. I'm not talking about changing behavior, I'm talking about changing implementation. Behavior is part of the contract. But being able to safely change implementation is the fundamental principle of abstraction and is the basis for polyphorphism. If a method today does a calculation using a database but tomorrow is refactored to use a webservice -- as long as the contract/behavior is unchanged -- then the rest of the code shouldn't have to know about it.

erikpukinskis 8y ago

This kind of thinking has permeated my coding practice. I used to think "this is hard, I need to learn about more systems until I'm smart enough to do this." Now I think "this is hard, there's probably something wrong with the architecture. I'll fix it."

wvenable 8y ago

That's the mistake with exceptions; if you assume every method can throw any kind of exception it actually reduces your cognitive load. Now you just have to worry about what you can handle in the 2 or 3 places in your code you can actually handle exceptions. Instead of infinite number of places an error can occur and the huge number of possible errors. The idea that error states are perfectly knowable everywhere in the code is a myth. Even if that were possible at one moment, the instant anyone changes code anywhere it will immediately be wrong.

lazulicurio 8y ago
> Now you just have to worry about what you can handle in the 2 or 3 places in your code you can actually handle exceptions This is only true if your application has no state or invariants that could possibly be invalidated in the face of exceptions. For instance, what would be your solution to the 'NotifyIcon' example given in the linked article? > The idea that error states are perfectly knowable everywhere in the code is a myth. Even if that were possible at one moment, the instant anyone changes code anywhere it will immediately be wrong This applies equally to both error codes and exceptions. If a method N layers down in your call stack changes its behavior, that's a potential breaking change regardless of your choice of error handling.
- wvenable 8y ago
  > For instance, what would be your solution to the 'NotifyIcon' example given in the linked article? The notify icon code is poorly structured to begin with. Simply creating a NotifyIcon object adds it to the UI? That's an awful design. If there was an add to UI step then it would be a non-issue; the half-constructed NotifyIcon object would never get added to the UI. This issue is not magically resolved by having to explicitly handle every error; you can make the same mistake with twice as much code. > This applies equally to both error codes and exceptions. If a method N layers down in your call stack changes its behavior, that's a potential breaking change regardless of your choice of error handling. I'm not talking about changing behavior, I'm talking about changing implementation. Behavior is part of the contract. But being able to safely change implementation is the fundamental principle of abstraction and is the basis for polyphorphism. If a method today does a calculation using a database but tomorrow is refactored to use a webservice -- as long as the contract/behavior is unchanged -- then the rest of the code shouldn't have to know about it.