IMO, Rust panics should kill the application... C# errors shouldn't. Also, in practice, in C# where I was dealing with Result, there was just as much chance of seeing an actual thrown error, so you always had to deal with both an explicit error result AND thrown errors in practice... it was worse than just error patterns with type specific catch blocks.

▲

mrsmrtss 4 days ago | parent | next [-]

I think you just had experienced a bad codebase. If you opt for using Result then you can not throw at the same time. If you follow this rule, then it works perfectly.

▲

tracker1 6 hours ago | parent [-]

The problem is, the referenced libraries can (and do) throw in practice... which means your own code needs to account for this. Most libraries in C# are written to throw errors, which means interactions will mostly need to account for these at some level, which is a pain. Not to mention, Task<Result<T>> is awkward in and of itself, because a task result is a success or fail, wrapping another type that is a success or fail. And such is the nature of async + result in C@, which is kind of redundant. Which, again, depending on the libraries in use, you have to account for and it is and will get messy.

	▲	mrsmrtss 5 hours ago \| parent [-]
		Yes, referenced libraries will throw exceptions, but since they don't return a Result type, there is no confusion either. We simply handle the exceptions where they arise. This means we don't need to handle exceptions all over the codebase. Also, a Task will only fail if there is an exception or it is canceled, so if you handle your exceptions at the source, you don't need to worry about them anywhere else.

▲

neonsunset 4 days ago | parent | prev [-]

[dead]