Exceptional results: error handling in C# and Rust
ruudvanasseldonk.com
ruudvanasseldonk.com
In user code (as opposed to framework code), Typed Exceptions are overrated.
Let's take these two cases:
1. End-User: Doesn't care if the Exception is a ParseException or an InvalidVersionException. Exception("Invalid number") and Exception("Version should be higher") is just as good enough for a message. Basically, for the end-user, the app crashed and that's it.
2. Programmer: Will have to open the debugger or check the code anyway.
I get it that it's useful in some cases, when you wanna send back some structured data to the caller. But in the vast majority of cases, the plain Exception class and Stack Traces suffice.
Generally speaking, that point doesn't care why the bunch of stuff five levels down went wrong. It just wants to report the error, and then either carry on with something, or let the user know what the problem was and decide if they want it to carry on.
Very occasionally, the actual type of the exception is useful. But mostly I just don't care about typed Exceptions.
Typed exceptions are not only idiomatic but deeply ingrained into the language core. Even basic primitives like loops use exceptions to control flow (StopIteration).
In reality, you would never call uint.Parse and let the exception bubble up, you'd call uint.TryParse and handle the logic for failure in the method. There is almost always a way to write your code so it doesn't throw exceptions. I'm working on a pretty large C# codebase for a SaaS website and by doing "find in all files" the keyword "catch" I came up with 174 references. For hundreds of thousands of lines of code, we have had to manually catch and handle exceptions only 174 times.
The fact that you have 174 catch blocks in a very large codebase only reinforces the blog's point, which is you may be missing error handling blocks or you just have very general handlers.
The only places where we need good exception handling is when doing I/O (network and filesystem). If you have proper layers to handle those things (with queuing/retrying/logging) you end up with a large codebase with very little places where you have to handle exceptions. Anything that is user-input we use TryParse and we do proper validation on the data before doing anything with it. This method is makes it easier to read because you know what the intent is better than doing parse/catch exception in my opinion.
At no point do you need to know exactly what methods trigger what exceptions. Yes, you do need to know the superset of all exceptions. But that's no different than knowing the superset of all methods or all classes. My point is, a mapping of methods to exceptions is unnecessary.
Interestingly enough, you might end up handling exceptions which can never be triggered by your application. But this isn't a bad thing, as this can make your application more robust in the face of change.
You need to decide where you're going to handle them, and this depends on how much context is required to handle them appropriately. Sometimes this may require doing it right at the point where the method is invoked that triggers the exception. Even if you decide to not handle the exception, you may still want to know the exceptions so you can rollback/adjust state/invariants before letting the exception continue unwinding.
I consider adjusting state based on the exception type poor design. That's very tight coupling. But even so, where you put that code is still independent of where exceptions are thrown. If your data state adjustment requires an exception type, check for that where that state change is appropriate. But what methods trigger what exceptions is still irrelevant.
Now, we can argue if you can ignore that, in a controlled environment, and get away with it most of the time.. But that's not what the article is about. He compares exhaustive error handling between the two languages.
error handling in general is hard to do; to have good, what i would call, "error partitioning"- catching errors/exceptions where they can be fixed is difficult- regardless of exceptions.
perhaps you got your error handling right and don't need more catch clauses, but if I was you I would investigate :)
> ...catching errors/exceptions where they can be fixed is difficult...
What's difficult? When your program is about to do something like say open a file - if you don't want an exception to be raised from that code, you wrap that code in a try...catch. In the catch block, you take corrective action.
The very simple bottom line with error handling in .NET apps is that you handle/log/notify the user at process and thread entry-points like main and AppDomain.UnhandledException. Other than that, you use a try...catch block.
Do you think it's a far stretch to say that people who actively use open source languages and libraries and contribute to Mozilla projects are much more likely to be biased against anything that Microsoft does?
public static UInt32 CheckNextVersion([...])
{
Contract.Requires(previousVersions != null);
Contract.Requires(versionString != null);
UInt32 version;
if (!UInt32.TryParse(versionString, out version)) throw new ParseException();
var min = previousVersions.Cast<UInt32?>().Min();
if (min == 0) throw new NewReleaseImpossibleException();
if (version >= min) throw new InvalidVersionException();
return version;
}
public static Result<UInt32> CheckNextVersion([...])
{
Contract.Requires(previousVersions != null);
Contract.Requires(versionString != null);
UInt32 version;
if (!UInt32.TryParse(versionString, out version))
{
return Result.Error<UInt32>("Bad version string.");
}
else
{
var minimumPreviousVersion = previousVersions.Minimum();
if (minimumPreviousVersion == 0)
{
return Result.Error<UInt32>("New release impossible.");
}
else if (version >= minimumPreviousVersion)
{
return Result.Error<UInt32>("Invalid version.");
}
else
{
return Result.Success(version);
}
}This is an important point imo. It is actually one of the ways you can describe to a non-programmer why it can be so hard to write typcial desktop software which never ever crashes (as in 'unhandled exception' dialog): huge amounts of time would be wasted to figure out for each and every single statement what can go wrong and how to handle it. Seriously, I've been at meetings where more time was spent on discussion on how to deal with/present to the user some obscure once-in-a-lifetime error than on actually fullfilling requirements.
That's how exceptions are supposed to work. The wack-a-mole attempt at ensuring you "handle" every case is wrong.
The problem, in my opinion, is that most programmers have been so brain damaged by Java that anyone exposed to that way of programming can't see how exceptions are supposed to work. Java not only makes you try/catch/declare everything but also makes you use exceptions for non-exceptional operations. A perfect storm.
The main issue I have with this technique is the higher mental overhead when getting started. That goes away with a bit of practice.
I don't know that it makes much sense on Error objects though, there's no requirement that they're even able to store backtraces, and collecting backtraces any time an error object is created would be really expensive and would make the runtime a dependency of errors.
Just printing stack traces is a distraction though. The only thing that is required that on an exception, the entire stack above the the exception site can be inspected in the debugger.
Unlikely. Scala gets tracebacks for Try because the left arm stores a JVM Throwable, and throwables reify a stacktrace during initialisation.
For Rust, this would mean:
* Result's Err mandates an Error (currently has no trait bound at all)
* Errors must be able to store a traceback
* Error/Result requires rt in order to collect a stacktrace
* Rather than stack-allocating a struct or two, Err results now require significant heap allocation and data collection completely breaking existing usage patterns
I don't do this in my Scala code because I rarely find I need a backtrace.
(I don't use `Try` for reasons described here: http://underscore.io/blog/posts/2015/02/23/designing-fail-fa...)
That's already possible, though it requires nightly as it's an unstable "feature": http://doc.rust-lang.org/stable/std/rt/backtrace/index.html
This will collect a stacktrace in the provided buffer, the result can then be stored in whatever object the developer wants (likely after decoding it to a String): http://is.gd/tOD8Ho
The fact that you know exactly what errors a function can throw is not an unique feature of monadic errors: in Java, you are required to explicitly list exceptions that a function can throw (checked exceptions), and you must handle every exception when calling the function.
The real feature of monadic error handling is that error handling become composable.
Imagine that you want to write a function that accepts three character-encoded integers and that you want this function to return the first integer it successfully parsed.
With exceptions, you will probably use a parseInt function with a type similar to:
fun parseInt(String) -> Int throws ParseException
fun getFirstInt(String a, String b, String c) -> Int throws ParseException:
try:
return parseInt(a)
catch e1:
try:
return parseInt(b)
catch e2:
return parseInt(c)
fun parseInt(String) -> Result<Int, ParseException>
fun operator <|>(Result<r, e> left, Result<r, e> right) -> Result<r, e>:
match left:
Ok(r) -> return Ok(r)
Error(e) -> return right
fun getFirstInt(String a, String b, String c) -> Result<Int, ParseException>:
return parseInt(a) <|> parseInt(b) <|> parseInt(c)
It's almost impossible to create this kind of operators with exceptions because they are not a return value, and thus can't be handled in expression. With monadic error, handling operators are just plain old functions.
The thing is, Rust's type system is currently incapable of expressing an GENERAL monadic trait/interface, which it would be, if it had HKT. (That would allow implementing all the additional monadic util methods as trait default implementations, and having generic functionality applying to any monad.) Hopefully we get there someday.
> On the other hand, what would a Rust
> programmer do to handle an out of memory
> situation?
"This type of OutOfMemoryException exception represents a catastrophic failure. If you choose to handle the exception, you should include a catch block that calls the Environment.FailFast method to terminate your app and add an entry to the system event log"
https://msdn.microsoft.com/en-us/library/system.outofmemorye...
Complaining about the existence of Parse is like complaining about the existence of unwrap in Rust.
C++ (another systems language) is probably a better comparison for out of memory.
On modern systems it's not possible for an application to know when memory has been exhausted, because of virtual memory and overcommit (http://www.win.tue.nl/~aeb/linux/lk/lk-9.html#ss9.6). The system will happily tell your process that memory is available even when it's not, and relies on the OOM killer to free memory by force when necessary. The only context in which an application can reliably detect OOM is when that application is the kernel itself.
Fortunately, Rust has a stripped-down version of the standard library, called libcore, that exposes features which don't require allocation and thus don't have to worry about OOM. This profile is perfectly usable for writing kernels, and could also be used to write an alternate kernel-specific stdlib which make it possible to handle OOM.
> Complaining about the existence of Parse is like
> complaining about the existence of unwrap in Rust.
How is Parse any less explicit than unwrap ?
uint foo = uint.Parse("3");
let foo: u32 = "3".parse(); // error: mismatched types
let foo: u32 = "3".parse().unwrap(); // just fine
uint foo;
uint.TryParse("Hello", out foo); // this compiles and runs!
Finally, this assurance extends in the other direction as well: knowing that libraries are architected to make errors explicit via return types means that if I don't get yelled at for not handling a return type, then I have peace of mind knowing I'm not overlooking anything. This is somewhat analogous to the considerable assurance given in knowing that types aren't implicitly nullable.
Now, if you're looking for something that can still go wrong, there's a better example then OOM: dividing by zero in Rust will implicitly panic. So while it's unlikely that a library author will use unwrap in their code (there's a strong culture against Rust libraries causing panics), it's possible that a library author could accidentally cause a panic by dividing by zero.
let foo: u32 = "3".parse().unwrap();
var foo = uint.Parse("3");
I agree that TryParse is worse than Rust's ADT approach, but that's a different issue, much like nullable references. The author is asserting that results are superior to exceptions and I am asserting that no, that is just a bad application of exceptions. Additionally, I am asserting that without exceptions, you limit what programmers are willing to propagate through their interfaces because errors become viral.
Isn't this true for all languages in one form or another? Go and Rust have "panics" Any code might fail exceptionally, stack overflows and out of memory conditions come to mind as relatively common ones.
The difference here is that C# treats more kinds of things exceptionally than Rust or Go. This seems to have more to do with Rust and Go ability to more easily return multiple types from a method/function and a philosophy of opt-in vs opt-out on handling an error.
I am used to C#/javascript so exceptions with try catch are very natural to me. Writing robust programs always involves handling everything one way or another. Even out of memory conditions can be handled and recovered if your always thinking that everything can throw.
The null issue is interesting, I like null, I like undefined with null even better in javascript. I always seem to need to encode something has no value or something was never even set vs picking a valid value as a special "no value" i.e. int.MaxValue or whatever. The only thing I would change in C# and javascript is null lifting object.property should not throw if object is null same with foreach over null object. They are adding the ?. for that but you need to explicitly do it, NullReferenceException is far to common in C# from those two situations explicitly. I belive Objective-C did some kind of null lifting where sending messages to null objects don't throw.
The concern does not make sense in Rust, Rust's panics can not be caught and will kill the current thread.
> The difference here is that C# treats more kinds of things exceptionally than Rust or Go.
Or it treats exceptions much less exceptionally than they do (Python being even further along on that axis), a C# exception is at best "uncommon".
> This seems to have more to do with Rust and Go ability to more easily return multiple types from a method/function
Rust doesn't use MRV for results, Result is a single struct (technically an enumerated type which can contain either a "valid result" or an "error result", not both).
> I belive Objective-C did some kind of null lifting where sending messages to null objects don't throw.
Not in the sense you think, Objective-C's nil is simply a black-hole, messages send to it don't do anything and return nil. It's possible (though not probably not recommended) to opt Smalltalk or Ruby[0] into this behaviour, because nil is a standard object not a magical special value (and both languages have open classes).
[0] http://blog.rubyenrails.nl/articles/2008/02/29/our-daily-met...
Things will go wrong. Some subset of things that can go wrong are things you want to do something about (e.g. file doesn't exist -- maybe prompt the user for a different file). The remainder are things you don't want to deal with (e.g. out of memory -- in most cases this is very rare so you're ok to just crash).
You want to arrange your program in such a way that you must deal with the errors you want to deal with. Your code won't compile if you don't. That is what this technique brings.
More here (though you probably won't understand many of the terms if you haven't used a modern FP-inspired language before): http://underscore.io/blog/posts/2015/02/23/designing-fail-fa...
Which would be fine but there is no way to do that without also having being forced to deal with the infinite errors you don't want to deal with.
I understand Rust's motivation for handling errors this way and it makes sense for the type of language it is. But in terms of computing science, it's a step back into the past. Just like manually managing memory.
"The consequence, when you want to write robust software in C#, is that you have to keep an MSDN tab open at all times. Can this method throw?"
First of all, assume every method can throw. Just do it. It's either true or could be true in the future when someone changes that method. Maybe it doesn't use the network today but tomorrow it calls out to a webservice. So all methods throw. And forget knowing what exceptions they might throw. That's an implementation detail and we want to hide implementation details.
"Should I catch a PathTooLongException here?"
No, you shouldn't. What are you going to do any differently with that than you would FileIsLockedException or NetworkIsDownException or HarddriveIsCorruptException? You wouldn't do anything differently. Show the user the ErrorMessage in the dialog and allow them to restart whatever operation was in affect. Let them choose a shorter path, close Excel, plug their Ethernet cable back in, or whatever. Trying to play wack-a-mole is a fools errand. Put MSDN away, you don't need it.
I don't think this approach works in general. Server software, at least, needs to automatically handle all these different failure modes in potentially unique ways.
For example, I might just catch every single Network exception, log it, add a timeout, and retry the operation. I'm not playing wack-a-mole and I don't care in the handler which of the thousands of methods called in my operation actually raised the exception.
The point is one should not be looking at what exceptions the methods throw but instead what exceptions can be handled. One set is very large the other set is very small. This applies equally well to server software.
I don't understand this viewpoint. If a file is locked, the user may be able to fix it, so go ahead and display an error. But if there is corruption, then what is the user going to do? You can't tell them, "Restore your system from backup, and then click OK." Your program has to crash before it causes more problems.
What if the situation is stack corruption or heap corruption? Or what if the error left the application in an inconsistent state? Continuing to run might corrupt the user's data. What if an attacker caused the corruption in order to gain unauthorized access? Logging or displaying the error might be exactly what they want.
I often see variations of this advice: If you don't know how to handle it, don't catch it. By definition, you don't know how to handle an unknown exception.
> Put MSDN away, you don't need it.
I think it is a good idea to understand the behavior and failure modes of every API function that you call; this requires that you consult the documentation.
Corruption is outside the state of this discussion. If half your app just overwrote the other half of your app, no matter what we say here is going to make any difference.
> Or what if the error left the application in an inconsistent state?
That's a good question. The other part (and in my opinion the important part) of exception handling is ensuring your stack unwinds correctly. Managed languages help this with garbage collection, resource-using statements, and finally clauses. C++ does it with RAII. This is typically just your normal resource cleanup; if you are cleaning up correctly without exceptions you'll cleanup correctly with exceptions.
> I think it is a good idea to understand the behavior and failure modes of every API function that you call; this requires that you consult the documentation.
You are right, of course. You should definitely know the behavior and failure modes of every framework and library you call. And you should consult the documentation for that. But what you don't need to consult (or even necessary know) is the mapping of every method to every exception. You should look at the total set of all exceptions and handle the ones you can handle.
You keep stating this, but it doesn't make sense. By definition, for you to handle it somewhere requires knowing the entry point to the call chain that may throw exception(s) that you decide to handle. At this point, you're wrapping some method invocation with a catch block, are you not? If so, you need to know that this method throws these exceptions. Sure, in some cases you may not care which of the tens of methods in the call chain actually triggered a SocketException, but that's a specific case and doesn't solve the overall problem. What if there are several sockets involved in the operation and you want to reconnect just the failing one, for example? At some point, you're going to have to sink your error handling to the point where you have enough context to handle it, which invariably means it's not enough to know the general types of exceptions an entire framework/library throws.
I think you're still missing the point and maybe I'm not explaining it well. For you to handle an exception, you don't need to know where something may throw an exception. You just need to know where you can handle the error. For example, if I'm iterating a data set and performing a web service call per iteration then I'm more than likely going to put my exception handling inside that iteration around that service call. My recovery is more than likely going to be retrying the service call a few times and then give up and iterate to the next item. Perhaps enough overall failures will terminate the whole loop.
So yes, at some point I will be wrapping some method invocation with a catch block. Does that method throw an exception? Yes. All methods throw exceptions.
> What if there are several sockets involved in the operation and you want to reconnect just the failing one, for example?
Obviously, you do need to put the exception handling code where you can reasonably handle the error. Which is just restating my point. If your code generates several sockets and performs operations on them then the error handling should be connected to those operations. So again the decision about where to put the error handling is not based on which methods throw (they all throw) it's about where it makes the most sense to handle it.
I believe exception handling should build up from the generic to the more specific as needed. If you have to handle every single exception at every call site then that's building it down from the most specific case. Java forces you to do this and it's almost always a waste of time and mental effort. It also makes iterative design difficult. Most first versions of my applications have just one single handler that logs everything and terminates. Many times that's good enough. But where it's not good enough, the next version can be easily improved with specifically targeted exception handling sprinkled in as needed.
Why? If corruption leads to an exception, it seems relevant. Corruption could be the application's own fault, it could be failing hardware, it could be someone trying to exploit a vulnerability. It could be anything - a result of undefined behavior. Sorry if I'm using the term loosely.
> If half your app just overwrote the other half of your app, no matter what we say here is going to make any difference.
If it overwrote the other half, it should crash immediately. I can't just display an error message and retry the operation in that case. If I don't know what exception I'm handling, how can I be sure that I won't cause more damage by handling it?
> The other part (and in my opinion the important part) of exception handling is ensuring your stack unwinds correctly.
That is not what I was referring to. A program can still get into an inconsistent state with exceptions. For example, if a function updates half of some data structure and then throws, that data structure may be left in an inconsistent state. Of course you should not write functions that way, but it is an easy mistake to make. Do you really want your app to keep running in an inconsistent state?
I'm looking at it from a defensive, assume-the-worse perspective. If my application is in an inconsistent state, it should cease running immediately. If my application does not know which state it is in, it must assume that it is in an inconsistent state.
You have to assume that code cleans itself up as the stack unwinds. That should be normal operation whether or not you are using exceptions or not. If the exception is in the middle of modifying a data structure then the cleanup should ensure that data structure is either back into a stable state or destroyed completely.
Exceptions or not, if you have an unknown error condition, how can you assume anything?
I apologize for the delayed response.
"Our goal is to write a function that takes a list of previously released versions and a user-provided version string, which then returns the parsed number or reports an error."
A function named CheckNextVersion should never even raise an exception because it expects bad input. It probably also shouldn't double up as the ParseNextVersion function as well. But I understand the author wanting to combine these operations and conveniently get an error message out that can be displayed to the user. But as a damning example of exception handling, it's just bad design.
So even if we accept the design, his method is horribly over-thought with regards to error handling. Either it should catch within it's body all potential exceptions and raise a single InvalidVersionException or it should catch nothing and the code above should catch everything and display the message to the user. All the work catching and rethrowing different exception types adds no value given the purpose of the method.
For floats there's partial_max() which returns Option<f32>.
It makes sense, but it never crossed my mind before that a simple max() function can fail.
It's also PITA to error-check such a simple thing, but somewhat surprisingly there's also f32.max() that works on garbage-in garbage-out principle.
So, my functions are ALL like this:
fun sample= StdOut(Str) | StdErr(Int) do
if GoodLuck() do
return "Yeah!"
fail 1
If the client wanna catch them:
result = sample() # Get the Ok value. if the Err value is returned, then trow like in exceptions
result != sample() # Get the Err value, not trow
result, err != sample() #Get both
So you're basically just using exceptions as syntatic sugar for return codes. Works reasonably well, I suppose.
That being said, I don't particularly like the overloading of `!=` there. I like the idea of a shortcut meaning "call this function and get the error value", but I wouldn't use `!=` for it.
Perhaps take a page from Lua's book and use `_` as a throwaway variable. So `a = foo()`, or `a,b = foo()`, or `_,b = foo()`.
That's exactly what Rust (to keep with TFA) does. Result is not really special, its core is just
enum Result<T, E> {
Ok(T),
Err(E)
}
That the code doesn't make sense, the result and the error should be exclusive propositions, why would you get both a result and an error when the function should return either one or the other?
Is modeled like unix IO (with stdin/out/err). Anyway, I think, a function/call get a value or a exception, so why not be more explicit about that?
Those are used for IO or user signaling, not error reporting (that's the process's return status, stderr may be used to augment it with a cause, unix utilities are centered about the status signaling correct/incorrect execution).
> I think, a function/call get a value or a exception, so why not be more explicit about that?
It's fine to be explicit about it (again that's what Rust does), the problem is your example isn't really explicit about it, and the second sample is downright weird. It's like Go except even more screwy.
edit: in an other subthread you mention following dynamically typed languages, if we go with that and assume no type support it makes slightly more sense, but the logic is still screwy: assuming the second snippet is a function which doesn't have a result (so it can only have an error) it should use the same system as the third snippet, the faulting assignment (first snippet) is the one which should use a different syntax.
And then there'a the question of what semantics you get when not assigning but just nesting expressions.
An option might be to attach the decision to the call instead (kinda like Swift) e.g. the result of a regular function call would be either `error` or `result, error` (with the language enforcing that one of result and error must be nil) but by "banging" the function the error is raised instead of returned. So you'd get something along the lines of:
# no result, possibly an error
err = foo()
# a result or an error
result, err = foo()
# no result, panics in case of error
!foo()
# a result or panics in case of error
result = !foo()
foo()
Not sure that's great, but it might be workable.
>if we go with that and assume no type support
Wonder why is harder with a type system (I say follow the syntax, not the type system of julia/python... so I wanna be as static as possible, or at least try)
A type system doesn't make it harder, it makes it pointless: when you have a good type system sum types[0] are a safer and all around better solution.
[0] possibly, in some cases, polymorphic variants https://realworldocaml.org/v1/en/html/variants.html#polymorp...
I wanna build a F#-like type-system with sum/products (https://www.reddit.com/r/fsharp/comments/30ywjy/question_how...) for my language, and be the result of the function already a Result<T, E>, without the user need to annotate it manually. So, I'm thinking in the kind of development that happened in reactive library but as a intrinsic model of the language.
Of course, I'm a total noob in this area, so still researching about this!
Here's a function that throws an error on odd numbers:
Try<int> Number(int x) => () =>
{
if( x % 2 == 0 )
return x;
else
throw new Exception("Any exception");
};
var res = match(from x in Number(10)
from y in Number(10)
from z in Number(10)
select x * y * z,
Succ: x => x
Fail: 0);
var res = match(from x in Number(10)
from y in Number(9)
from z in Number(10)
select x * y * z,
Succ: x => x
Fail: 0);
var res = Number(10).IfFail(0);
TryOption<int> Number(int x) => () =>
{
if( x % 2 == 0 )
{
if( x > 10 )
None;
else
return Some(x);
}
else
{
throw new Exception("Any exception");
}
};
var res = match(from x in Number(10)
from y in Number(10)
from z in Number(10)
select x * y * z,
Some: x => x,
None: 0,
Fail: 0);
var res = match(from x in Number(10)
from y in Number(9)
from z in Number(10)
select x * y * z,
Some: x => x,
None: 0,
Fail: -1);
var res = match(from x in Number(10)
from y in Number(20)
from z in Number(10)
select x * y * z,
Some: x => x,
None: 0,
Fail: -1);
TryOption<string> DoStuff();
string DoStuff();