Vexing Exceptions(ericlippert.com)
ericlippert.com
Vexing Exceptions
https://ericlippert.com/2008/09/10/vexing-exceptions/
14 comments
I agree with the classification of TA, but I disagree on the "vexing exceptions". Even if you get a `Result` that you can pattern match over, the error handling code looks exactly as ugly if you put it into a pattern match branch as inside of a `catch` block.
I slightly disagree. I think two things are better with the result type:
1. Exception overhead. Exceptions capture diagnostics and unwind stacks in ways that add cost to the user-error case.
2. Type system information. With the result type, you declare the possibility to fail, and exactly what failures to expect in normal operation. You can switch over specific errors vs the broad category of anything that inherits from `Exception`
1. Exception overhead. Exceptions capture diagnostics and unwind stacks in ways that add cost to the user-error case.
2. Type system information. With the result type, you declare the possibility to fail, and exactly what failures to expect in normal operation. You can switch over specific errors vs the broad category of anything that inherits from `Exception`
> Don’t catch fatal exceptions; nothing you can do about them anyway, and trying to generally makes it worse.
Yes there is something: you can design an exception handling system which lets your code specify choices about what to do if such an exception occurs within its contour. Those choices provide ways of passing control to that code.
Then the next layers above the code can decide whether to take those choices, or some other similar choices available from eslewhere, or let the exception bubble up, possibly leaving it unhandled.
The article is a decent tutorial for working with Blub exceptions, but it's limited to that.
Yes there is something: you can design an exception handling system which lets your code specify choices about what to do if such an exception occurs within its contour. Those choices provide ways of passing control to that code.
Then the next layers above the code can decide whether to take those choices, or some other similar choices available from eslewhere, or let the exception bubble up, possibly leaving it unhandled.
The article is a decent tutorial for working with Blub exceptions, but it's limited to that.
That's try-catch. But you missed the point: you can't do anything about fatal exceptions such as an OutOfMemoryError.
Untrue. The circumstances of an OOM can be arranged in such a way that an emergency stash of a small amount of memory is available to meet the needs of some clean-up task.
Those stashes (and things like caches) should use SoftReferences so the GC can drop them under memory pressure. That way no funny stuff needs to happen in catch blocks.
Throwing exceptions in out-of-memory cases or something similar has no sense, since no real program can handle such exceptions properly. Throwing exceptions in cases of logic errors (like accessing an array with invalid index) has no sense, since they just conceal bugs. In other cases it's unclear what is exceptional and what is not. So why not just using normal control flow? That's why I personally use no exceptions (I program mostly in C++ and Rust).
> Throwing exceptions in cases of logic errors (like accessing an array with invalid index) has no sense, since they just conceal bugs.
Catching (and not logging) the exception would conceal the bug, but I wouldn't want to get rid of the stacktrace that comes with throwing the exception - that is extremely useful for narrowing down the location of the bug.
Incidentally, that's something I've never understood in the "Go style error handling" crowd. The default behavior - if you ignore the return value - in those languages is exactly equivalent to catching and silently throwing away an exception - the thing that's universally understood to be a bad idea. Whereas the default behavior in languages with exceptions is to print the error and exit the program - which us usually seen as the safest choice, unless you have more information and can recover from the exception.
So if go-style error handling makes it easier to do the bad thing instead of the good thing, why would it still be the superior form of error handling?
Catching (and not logging) the exception would conceal the bug, but I wouldn't want to get rid of the stacktrace that comes with throwing the exception - that is extremely useful for narrowing down the location of the bug.
Incidentally, that's something I've never understood in the "Go style error handling" crowd. The default behavior - if you ignore the return value - in those languages is exactly equivalent to catching and silently throwing away an exception - the thing that's universally understood to be a bad idea. Whereas the default behavior in languages with exceptions is to print the error and exit the program - which us usually seen as the safest choice, unless you have more information and can recover from the exception.
So if go-style error handling makes it easier to do the bad thing instead of the good thing, why would it still be the superior form of error handling?
Catching exceptions caused by a bug has no sense in production code. For debugging purposes exceptions aren't necessary, a compiler can just insert asserts and call stack printing at the place where a bug was detected.
I agree that errors handling as it is implemented in Go is error-prone. Rust does this much better - values of a Result type shouldn't be discarded.
I agree that errors handling as it is implemented in Go is error-prone. Rust does this much better - values of a Result type shouldn't be discarded.
You are not supposed to catch such exceptions in the first place, except at the very top level as a fallback to implement proper logging and to signal an unexpected internal error to the user. In Java, such exceptions are subclasses of RuntimeException.
Just printing a warning is not always appropriate. The code would continue to work and produce invalid data and actions.
Just printing a warning is not always appropriate. The code would continue to work and produce invalid data and actions.
> For debugging purposes exceptions aren't necessary, a compiler can just insert asserts and call stack printing at the place where a bug was detected.
For that, you'd have to know the location in the first place, which you usually don't.
For that, you'd have to know the location in the first place, which you usually don't.
The classification is probably right, but this post feels half-baked. There are some valuable points in here (never suppress exceptions that indicate programming errors!) but it's missing guidance on how to handle cases like bad user input, and how to actually do the exception handling for cases like file not found.
I don't think there is a lot of guidance you can give in those situations, as the right ways to handle those exceptions are highly context specific. But the point is that you can handle them at all, as opposed to the other types.
Perhaps it's an artifact of C#, exceptions are built into the language and sufficient user error handling mechanisms are not. You get some `Try*()` methods but often don't have as much error information as you'd like.
You can mimic Rust's `Result` pattern in C# without much trouble and I've found that to be a good way to go. The biggest downside is the lack of namespace-level typedefs so you always have to include that TError parameter. It's a small price to pay.