On the same topic: When An Error Is Not An exception Series: https://dev.to/vncz/series/6223
Away from Exceptions: Errors as Values
81–90 of 145 posts
Re: Away from Exceptions: Errors as Values
#82No, I don't want to wrap every single statement of my program in its own if-block, thank you very much.
If you have to do this, the structure of your program might be wrong.
Don't check the return value of a call to the same API multiple times. Make it such that all calls to the API go through the same code that you write, so you have to check the return value only "once". This may sound extreme, but it's pretty close to what you can realistically achieve.
You can achieve that trivially by exiting if something goes wrong when calling the API. And where exiting is not possible because it's a longer running application, concerns have to be separated: If there are multiple pieces of code that need the same data, feed those pieces the data they need from a central location that interfaces with the API. And have the error handling logic (which is usually higher level control logic) in the central location.
Re: Away from Exceptions: Errors as Values
#83[deleted]
Re: Away from Exceptions: Errors as Values
#84I'm firmly in the camp that believes that exceptions are a false economy. The post links to an "Exception Smells" post that doesn't mention one of my pet peeves: exceptions as control flow. For example, Java's parseInt [1] throws a NumberFormatException if the string can't be parsed. IMHO this is terrible design. As a side note, checked exceptions are terrible design. I wrote C++ with Google's C++ dialect where excep…
Checked exceptions are horrible to work with, but they require the programmer to do something about them at the level immediately prior while as unchecked exceptions could just bubble up to an unexpected point in the stack which is arguably worse.
Re: Away from Exceptions: Errors as Values
#85Earlier quoted context omitted.
In the end that is equivalent to bubble up exceptions when thy are of the unchecked type.
I don't think that's true because if I understand it correctly, the return type of functions which can possibly throw unchecked exceptions would not indicate that they can throw or what they can throw. On the other hand, with the "errors as values" approach (including "bubbling up" operators like `?`), you can tell exactly from the function's return type if an error can be returned and if so what the set of possible…
> the return type of functions which can possibly throw unchecked exceptions would not indicate that they can throw or what they can throw
As far as I know, that's how Java's "throws" method signature works, which has been widely regarded as a mistake.
Re: Away from Exceptions: Errors as Values
#86>Only throw exceptions when something really bad has happened and the program must stop. For example:
> the program cannot connect to its database;
> the program cannot write output to disk because the disk is full;
> the program was not started with valid configuration.
I'd prefer Result over exceptions even in these cases. The only case where I think exceptions should be used is when the type system of the language is not powerful enough to prove the validity of some operation. For example in Rust:
let v = vec![1, 2, 3];
let n = v.pop().unwrap();
Another example is division by zero. Using a `Result` as a return value of the division operator would be extremely inefficient and unergonomic. Panic/exception is the best way to handle this situation.
I believe dependent types can solve both of the problems above so we can get rid of exceptions completely. Unfortunately, there is no a single mainstream language that has them.
Re: Away from Exceptions: Errors as Values
#87Errors as values are fine and useful. However author also says this:
"Programming with exceptions is difficult and inelegant."
I am of completely opposite opinion: to me exceptions are very easy to use and elegant for what they intended. It does not mean that one has to rely only on exceptions or on plain error as values. Use both for the best benefits depending on situations. Why programmers get obsessed doing thing in "there can be only one right and true tool language, concept, style etc. etc." way is completely beyond my understanding.
Re: Away from Exceptions: Errors as Values
#88[deleted]
Re: Away from Exceptions: Errors as Values
#89To whomever is going to implement this: Please save the stack trace into the error object at its creation time, at least in debug builds.
On Windows, there is an API for this - https://docs.microsoft.com/en-us/windows/win32/api/errhandli... - you can save the callstack there, before a C++ exceptions happens.
Re: Away from Exceptions: Errors as Values
#90It's good to see so much focus on errors. They are essential when trying to build resilient systems. But our approaches are still very immature. First, to make it clear, this article appropriately points out that exceptions are still necessary and relevant. I disagree with some of the use-cases given, but it's important to recognize that exceptions should still exist in programming languages. Joe Duffy's article abou…
We can't forget that "error handling" is a civilization-level hard problem. Do you set up support structures to catch them when shit hits the fan, or do do you preventatively and excruciatingly suppress them? It's as much a theoretical problem of what errors are as a practical problem in how to represent these intricate models ergonomically, and what will be sacrificed. In some sense it's an almost moral question!
And then throw PII concerns into the fray. How do you report meaningful information to your ops team but still not expose PII in your logs. There's ways of course but its not trivial.