61–70 of 145 posts
No, I don't want to wrap every single statement of my program in its own if-block, thank you very much.
This was bread and butter error handling in COM, everything old is new again!
https://docs.microsoft.com/en-us/cpp/cppcx/exceptions-c-cx?v...
https://github.com/microsoft/wil/blob/5a21cac10640f54b7ef886...
https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-a...
Earlier quoted context omitted.
This was bread and butter error handling in COM, everything old is new again!
Yep, all hail the mighty #define CHECK(com_expr) hr = (com_expr); if (FAILED(hr)) { return hr; } Ah, the memories... glad I don't have to touch it ever again. "And a million other things that, basically, only Don Box ever understood, and even Don Box can’t bear to look at them any more".
Even if they are eventually wrapped in .NET libraries.
It looks like GO developers never heard about "not repeat yourself", because after almost each call in GO, you write boilerplate error checking code... So you end up writing at least 2 times more lines of code.
It was a very conscious decision by go devs. To enforce local error fixes instead of the usual wrap and throw the exception again.
Earlier quoted context omitted.
You need all those error check code if you want to recover from error -- regardless of whether the error is coming from exception or value. If you don't want to recover, just throw it down the stack that will exit, then can you do that without exception too. Just call error() function on error which will print the error and exit(-1). No need for per-line error checking in this case too.
You don't need it everywhere. With both exceptions and error monads, you can have a happy-flow path that mostly leaves out the boilerplate, and handle errors at a reasonable point. Go forces you to add even if you want to defer handling to a later point.
Earlier quoted context omitted.
Rust solves this issue by having a ? operator to bubble up Errors. Before that there was the try! macro with the same semantics. That cuts the boilerplate to a minimum while having a well defined and explicit control flow. I agree that if you had to write the ifs by hand it would be a pita. Looking at you, Go.
In the end that is equivalent to bubble up exceptions when thy are of the unchecked type.
Earlier quoted context omitted.
> For example, Java's parseInt [1] throws a NumberFormatException if the string can't be parsed. IMHO this is terrible design. It's unergonomical design, but it's the _correct_ design: the method is declared to return an int, and it can't fulfill its promise: throwing an exception is the right thing to do.
But the mechanism is just wrong; Exceptions are heavyweight and should only trigger with unexpected issues, bugs that a developer wants to see a stacktrace for. I mean in this case you could consider it developer error; a developer tried to parse an integer without first validating the input and checking if it COULD be parsed. But it's normalized to just "let it crash", instead of writing additional pre-check code. W…
Is there a meaningful difference between validating that input can be parsed and parsing it?
Any validator that doesn't actually parse the data - according to the same rules the parser uses - runs a risk of incorrectly passing/failing certain cases, no?
Earlier quoted context omitted.
> The compiler should force you to handle every exception in some way, or to check for it. This is the single most unproductive mis-feature a language could have for me. Programming is already a tedious excercise of wrangling your thoughts into an alien form the computer can understand. You want, on top of everything else, the computer to refuse to run your program at all, unless you explicitly handle every possible…
I don't quite follow. You always have to somehow handle the case the file does not load successfully. In exception languages that handling might be implicit (raise an exception and crash your program) and in "errors as values" languages you at least have to acknowledge that it could go wrong with something like `image.unwrap()` (which turns it into a program aborting panic).
I.e. you don't have to handle it.
Until you're polishing the program for a stable release, that is.
Earlier quoted context omitted.
I don't quite follow. You always have to somehow handle the case the file does not load successfully. In exception languages that handling might be implicit (raise an exception and crash your program) and in "errors as values" languages you at least have to acknowledge that it could go wrong with something like `image.unwrap()` (which turns it into a program aborting panic).
> You always have to somehow handle the case the file does not load successfully. In exception languages that handling might be implicit I.e. you don't have to handle it. Until you're polishing the program for a stable release, that is.
On the contrary, when you later want to polish your program for release these explicit markings make it very easy to find the points in your code where errors can occur and which you don't properly handle yet.
Earlier quoted context omitted.
Yes. What I'm thinking of are _not_ checked exceptions, at least not at compile-time.
Can you elaborate then?
> Some errors are unexpected and should stop the program; you want to use exceptions for those. Precisely the opposite: exceptions are a fail-fast mechanism that gives you an alternative to terminating the program. Now, as slx26 mentioned, it's only half of the story. Most APIs (including .NET) document exceptions badly, they're not discoverable, and if you try to use them to _recover_ from a condition, you're in for…
"> Some errors are unexpected and should stop the program; you want to use exceptions for those. Precisely the opposite: exceptions are a fail-fast mechanism that gives you an alternative to terminating the program." I don't see how this logic flows. Exceptions do give you the alternative to recover, sure, but the author is saying 'the kinds of errors that produce states where you should stop the program ... use exce…
The author wrote "stop the program". I took it to mean literally: stop the program, i.e., exit immediately, i.e., crash. That's not acceptable in long-running "service" programs.