Lead Product Evangelist @Kentico, Founding partner @craftbrewingbiz. love to learn / teach web dev & software engineering, collecting vinyl records, mowing my lawn, craft 🍺
I use a Result<T> type, mostly as the return for calls to services / data access abstractions.
I then have conditional blocks like if (result.IsFailure) { ... } or if (result.IsSuccess) { ... }.
If it's a success, then the .Value type T property will be populated. If it's a failure then the .Errorstring property will be populated.
I think Option, Maybe, Result are all valid and the word used depends on your team. Option/Maybe feel a bit more functional and academic. I like them in F# but they feel a bit foreign in C#.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm using the Maybe Monad, which appears to be almost the same as Options.
I also like the word 'maybe' better than 'option', so I might be biased 😄
Imo Maybe.IsSome and Maybe.IsNone sounds better than Option.IsSome and Option.IsNone
I use a
Result<T>
type, mostly as the return for calls to services / data access abstractions.I then have conditional blocks like
if (result.IsFailure) { ... }
orif (result.IsSuccess) { ... }
.If it's a success, then the
.Value
typeT
property will be populated. If it's a failure then the.Error
string
property will be populated.I think Option, Maybe, Result are all valid and the word used depends on your team. Option/Maybe feel a bit more functional and academic. I like them in F# but they feel a bit foreign in C#.