Optional
kotlin-result
Optional | kotlin-result | |
---|---|---|
6 | 35 | |
876 | 937 | |
- | - | |
0.0 | 8.8 | |
8 months ago | 12 days ago | |
C# | Kotlin | |
MIT License | ISC License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Optional
-
Nullable vs Option
Since then C# introduced nullable which takes away some of the needs for a Option type. So what is your opionion? Do libraries like Optional still have a place when nullable is enabled?
-
It seems like I'm forced to make this choice at least once a day
Optional is my go-to for c# (you could also use the F# Option of course but pulling fsharp.core into a C# project tends to raise eyebrows in my experience)
-
Common C practice to avoid in C++
This library provides similar functionality to F#'s Option type. I can't vouch for it, but it's there.
-
Why GoLang supports null references if they are billion dollar mistake?
Not really. C# doesn't have monads but you can easily add something like https://github.com/nlkl/Optional which is great for a team familiar with option types and IMO will lead to a more productive team with a more concise code base.
-
How do you handle EF Core null return values in your projects?
You can use Optional
-
How to get rid of NullPointerException
The option type is a different way to represent an optional value. This type asks if a value exists and, if so, accesses the value. When trying to access the value which doesn’t exist, it raises an exception. This solves the problem of NullPointerException raised in code areas away from the bug. In Java there is the Optional class. In C# (until C# 7 ) there is the Nullable type which is only for value types but you can create your own or use a library.
kotlin-result
-
JEP draft: Exception handling in switch
Author here. I have no idea what you could possibly mean with this comment. The coroutineBinding implementation correctly uses the coroutines API for parallel decomposition of Result bindings, exactly how the Kotlin Corotines guide tells you to (backed by a [Mutex](https://github.com/michaelbull/kotlin-result/blob/master/kot...)). The coroutineBinding isn't even the main selling point of the library, you can use it without using this feature entirely.
Please could you elaborate on what "looking thread safe" means to you? The only portion of the library that supports concurrency *is* thread safe - the unit tests prove it and the use of concurrency primitives such as Kotlin's Mutex are indicative of this. I truly have no idea how you've judged the entirely of the lbirary on whether it's "thread safe" when there is a single function that's related to concurrency and it is very clearly using concurrency primitives.
-
How do you define errors?
Sealed classes in combination with a library like https://github.com/michaelbull/kotlin-result will get you what you need. Essentially at that point you'll be doing error handling the way you would in Rust, where a 1-level deep sealed class containing data classes as children act as the root error type and each of its variants. If you have errors coming from two different domains you just create a wrapper error type for each domain.
-
Result Class with Generic Type for both Success and Failure States
This is a great result lib: https://github.com/michaelbull/kotlin-result
-
Is runCatching in use in any of your projects ? My team is abusing it
Lastly I do not like kotlin's Result and we use the kotlin-result library which is more expressive and not tied to Throwable (similar to Arrow's Either).
-
Struggling with software robustness with Kotlin
In my own code, I started to use explicit error handling. I'm currently experimenting with Result (from https://github.com/michaelbull/kotlin-result) and Raise (from https://arrow-kt.io/).
-
Thoughts on Kotlin Multiplatform?
un-related to multiplatform i've found it extremely helpful to wrap things in a Result type. If something can throw an error, it get's a Result return type. It sounds like that would help your use case too. The built in Result may be useful too
-
Programming with Result
This is a better impl.
- It seems like I'm forced to make this choice at least once a day
-
Are nearly all your functions suspend?
Using a result type can help to differentiate quite nicely. https://github.com/michaelbull/kotlin-result
-
Kotlin Nitpicks: Language and Standard Library
kotlin-result
What are some alternatives?
language-ext - C# functional language extensions - a base class library for functional programming
result4k
JFlepp.Maybe - A Maybe type for C#, aimed as an idiomatic port of the option type in F# to C#
kotlin-monads - Monads for Kotlin
Curryfy - Provides strongly typed extensions methods for C# delegates to take advantages of functional programming techniques, like currying and partial application.
Result - The modelling for success/failure of operations in Kotlin and KMM (Kotlin Multiplatform Mobile)
MoreLINQ - Extensions to LINQ to Objects
Arrow Meta - Functional companion to Kotlin's Compiler
Optuple - .NET Standard Library for giving (bool, T) Option-like semantics
Komprehensions - Do comprehensions for Kotlin and 3rd party libraries [STABLE]
NullGuard - Adds null argument checks to an assembly
Kategory - Λrrow - Functional companion to Kotlin's Standard Library