The difference is all the pain is upfront instead of spread out over years of production bugs. So really the decision of using the result type is down to whether you reckon you'll still be working on the code in a year or two...

Today is the first time I've heard of "railway pattern", why does this make so much sense.

Welcome to F# :)

@@dolgan12 While I love this way of writing code, I can't subscribe to any love for F# in it's current form. And that's purely personal rooted in habit.

@@orterves This method is error prone if someone fails to check for result.IsError before using it. So you still have the same issues as when someone fails to handle an exception. Which means you still have to wait for exceptions to present themselves in production. So what are you avoiding exactly? The only benefit of this approach is performance (since exceptions in C# are really slow), and more explicit code (which doesn't necessarily make it less error prone, only easier to follow when you're tracking down errors).

This is probably a better introductory video: kzfaq.info/get/bejne/i7lohKpqrpe8h2Q.html

Yeh I was using this library in 2016 but now you can't get a job unless you program in the exact way that Uncle Bob says.

@Mortizul but that's a problem in the making. Nothing wrong with convention or best practise, but maintainence, understanding, and reality kick in. It may make things cleaner but does it provide totally clarity, but overall we deal in logic 1s or 0s, true or false Soap box getting off, it also makes the complex seem simpler, but at an expense

Our team is using it as well

would u plz share ur ApiResult class?

Lol same. I was also watching his same video and actually looking if he had a video on Results.

But isn't that the purpose of nullable types?

@@neociber24 True. But nullable type can let you ignore the potential null as an outcome. Nowadays, null can help with interconnection with C APIs and other third party stuff. Also, nullable type handy when you want to optimize internals of your implementation. But in terms of pure C# API it's meaningless and good plant for potential bugs. Same goes for interface: if your interface has a null for specific type as an potential outcome - this is a code smell

This is not a new phenomenon. Many of C#'s features were inspired by F# equivalents, and often F# was inspired by other ecosystems. async, switch expressions/pattern matching, records, etc. It's a shame more .NET devs don't try F# because there are a slew of important features - and a different way of thinking about programming - that simply cannot ever translate into C#. And, in fact, I'd argue that C# is getting more and more complicated trying to bolt on these things that are not a natural fit due to its inherent design philosophy.

@@AnythingGodamnit It's not that new indeed as I've been using delegates/anonymous functions as lambdas since the mid 2000s (I think it was C# 2.0). It was clunky to use back then but I had a FP course at the university and was very eager to use all those slick patterns to solve real problems at work. C# is showing its age and some new features have rough edges or look bolted on indeed (one of the saddest causality is how NRTs are handled - better than nothing though!) but overall, the language doesn't feel all bent out of shape to me and most FP features added over time are really convenient and pleasant to use.

Yep! It is wildly used in functional languages, and as Mads Torgersen said: "OO is kind of screwed... it was not designed for the cloud". -> kzfaq.info/get/bejne/ebJ7jZqLzLzNlKM.html

@@iuribrindeiro5009 DO you know that there is something called industry standard languages and growing languages? And toy languages?

@@obinnaokafor6252 I'm not sure what do you mean by "toy languages" but I think I do understand related to the other 2. Functional is not a language but a paradigm created on early 30s, if that is where u are going with. Don't get mad, I'm just replicating what the C# lead designer said :)

Agreed.

Exactly. Argument against throwing exceptions is “exceptions are expensive” and argument against Result types is “there is a lot of checking”. I personally prefer throwing exceptions because I can just throw exceptions and be done with it.

that's the caveat but also the advantage of it. believe or not, there's a LOT of programmers that do not handle exceptions. And even when they do, they don't actually simplify the exceptions or even rethrow them.

hello, could you please give me the link to the code about this idea (converting object result to IActionResult)

@@hhgforfhuv I don't have a link about this at the moment, but I'll write up a blog post in the next couple days and give you that link. :)

He does not use f#

If it succs then it is okay 😅

Option is not the same as nullable. You can wrap it, but it is different.

@@crazyst3ve01 Sure, it's not the same, but the semantics are similar enough for most use cases

😳 sorry but how can you write thesis about minimal api, what is scientific about it? It’s just way of organizing you endpoint, who cares if it’s based on mvc , or any other concept, it’s point is to allow hit you http server and get desired resource based on ‘path’(http request) Back to the video, This concept of result monads is only a way of flow control that language like rust, functional supports and c# tries to mimic. It’s great but it’s will hard to add native support because all standard libraries should have been rewritten to not throw the exception but rather expose it as a monad, and some api would also has to change. Basically even string parse would need to be rewrites to plainly admit that hey you can get an string or errorX and when you get error do something with it, or at least panic ;) it’s embarrassing that so many people are overwhelmed and treat it like a genius revolution, but it shows how advanced programmers are these days 😢😂 And of course I would love to have it in c# and I am trying to adopt it as much as I can in my application code. Maybe eventually even some libraries starts to be based on that idea and c# devs teams figure somehow how to add support with maintaining the backward compatibility 🎉😃

@@brtk7 well, we don't have overwhelming requirements for our workaround, so I picked this topic for some sort of experiments. Yes, you can say that it's just a technique for API structuring, but as Nick mentioned it can give you the possibility to build a new approach So it can be something that simple. Other people in our university literally picked up topics like Spring Boot WebFlux or just CRUD applications

@@winchester2581 you could instead build your own custom middleware on top on asp and invent, research new way of building api, that would have better way of defining these endpoints or even get rid of asp and incorporate simple http library or use standard code primitives like httpListener. And that would add value to your project and present you more like a researcher rather than a technical noob getting existing with technology that doesn’t completely understand. Sorry for that, but If I were to appreciate such projects, I would insult people who truly strive and put effort into their thesis work. 🥲😁

True, but you'll probably lose a lot of performance with the boxing. If that's not important in your use case, then by all means, go for it.

@@RobinHood70 not a lot in most cases. Plus usually it used for classes, so everything already boxed.

@@RobinHood70 you might pay some price. Easily testable with benchmarkDotNet:)

if you use for error something like rust enums you don't need extra parameters

I started using OneOf after Nick showed it in a video a couple months back. I was wondering why would you use a Result class instead of OneOf. It seems like OneOf would be more flexible.

Interesting question. A lot of SDKs do use exceptions for things like 404, 409 and 429.

Yes and this is the performance gain!

@@weluvmusicz Sure, but it is not clear, you expect stack trace from exception. It is better to use some different class in such cases, when you don't need exception.

I use both. I use OneOf generally and I have a result type through oneof

This is coming natively in C# as a feature as well

Oh boy, even haskell have EXCEPTIONS, even rust have panic. It's about how do you wrap your exceptions. You can wrap your httpClient calls with Either monad, you can wrap your db calls with Either etc.., but other parts of code should be pure and don't get divergence.

I'm working on exactly the same 😂 very interesting to dive into the roslyn analyzers

​@@BillieJoe512 It's very fun (not every time hahahahaha) to work with them, I kinda like the whole roslyn thing. If they made roslyn source generators to be able to modify the source code I would do something like function inlines for those .Match functions over result types, but until this occurs I work with the available tools

I’m using ErrorOr now for most things, having previously used LanguageExt. It’s quite simple/basic, but it is easy to get people onboard.

But from what I see in the video, he is using it to handle expected error conditions. If an exception was thrown because something exceptional occurred, wouldn't it still bail out as you say? If I understand your comment, it sounds like you're talking about catching any and all exceptions then returning them in a Result, otherwise how would it keep going. I'm of the opinion that exceptions should be for exceptions. If a function call had an expected error, then handle it, even if it means the request can't continue and you return a bad request.

Rust says hello and points out that in a safe and robust language with result and option types you don't need exceptions at all and your code becomes much cleaner and easier to reason about. Exceptions are just bad way of dealing with control flow and errors and make your programs much more complicated than they need to be.

@@reikooters If the error conditions are expected, well defined and narrow in scope then yes, Result may be appropriate. Examples include such things as TryParse and TryCreate, or requesting a resource that may or may not exist, or validation. But that is something that needs to be made clear, otherwise you will end up with people using Result for everything, and getting into trouble as a result.

This is at least very misleading. Yes, fatal errors should be fatal. But that is not what most people use exceptions for. They have become some sort of goto statement and abused for flow control. A file or directory doesn't exist or can't be accessed? For interactive applications this certainly isn't a fatal condition. The error should be communicated to the user instead, letting them pick a different file or folder. Yet, the Microsoft API's for filesystem access throw instead of forcing you to appropriatelyhandle the situation in the calling function. Forgot that try-catch? Too bad. Boom. Imagine your IDE shutting down everytime there's a syntax error in your code? Yeah, ridiculous. That's why in virtually every safety critical domain I've ever seen, exceptions are tightly regulated and only allowed for truly fatal situations.

@@matthewr8502 Really? If exceptions are a bad way of dealing with control flow and errors, and really do make your programs much more complicated than they need to be, then exactly what problems do they cause and exactly what complications do they introduce? Remember: "safe and robust" means that you make it easier to get things right and harder to get things wrong. That means, among other things, making the safe course of action the default. As I said, continuing regardless after an error has been encountered is not a safe course of action and should not be the default.

you only need to match this in one place per request

Yeah I'm not a fan of it. It's C error codes all over again.

Because you are not forced to do it

You could, I actually use both depending on the use case. The good thing about Match is that it forces you to handle both cases and also extracts the type from within the result, so you can give a better name to that than result.Value or result.Result

Because the Map and Match methods can be easily chained

Chaining, as Valera says. But also, Monadic approaches have their own context and semantics. With using the traditional if/then, you're not forcing yourself to continue to return more monads. You're sucking out the value and operating on it. But if you use Monadic semantics and methods like Bind and Map (sometimes Match), you both consume a Monad, and you return a Monad. Using result.Result outside of Map/Bind/Match makes this pattern lose its power.