Colton Idle
04/19/2021, 5:20 PMVampire
04/19/2021, 5:29 PMColton Idle
04/19/2021, 5:53 PMErrorCodes.WARNING
for example.Vampire
04/19/2021, 5:54 PMnanodeath
04/19/2021, 5:58 PMobject
)Colton Idle
04/19/2021, 5:59 PMnanodeath
04/19/2021, 6:03 PMErrorCodes
a real class, or just a bag of properties? could possibly also be an enum classColton Idle
04/19/2021, 6:05 PMobject ErrorCodes {
const val SOME_ERROR = -1
const val SOME_WARNING = -2
...
}
nanodeath
04/19/2021, 6:06 PMColton Idle
04/19/2021, 6:11 PMAlan B
04/20/2021, 12:12 AMenum class
, as you can use them in when
expressions (and other things), and then they truly represent a type ErrorCode
Constants like that are then really just “Ints” but you lose all the goodness of a better abstraction (the enum class), as an object
used that way can’t enforce usage of the error code as any Int can be passed in to whatever you’re using these for.
Also, when you use a when statement without an else
, they must be exhaustive and you won’t miss an error.
enum class ErrorCode(val number: Int) {
SOME_ERROR(-1),
SOME_WARNING(-2)
}
val error = ErrorCode.SOME_ERROR
fun handleError(error: ErrorCode): String =
when(error) {
ErrorCode.SOME_ERROR -> "Error"
ErrorCode.SOME_WARNING -> "Warning"
}
nanodeath
04/20/2021, 12:16 PMAlso, when you use a when statement without anif used as an expression 🙂else
Colton Idle
04/20/2021, 12:24 PMAlan B
04/20/2021, 1:32 PMvar
as much as possible, which is usually about 99.9% of the time (statistic made up, but just for a point and my example broke my rule for brevity hah.) IntelliJ warns about not being exhaustive when not using it as an expression so I missed that on my example, as I mentioned I tend to always use expressions, but it didn’t make sense for the example, but my example was a bad one. I’ll fix that.@Nullable
). People will forget to use them if it’s not enforced by the compiler, so really hard to trust. In the case of that sealed class example, it means that everywhere that class hierarchy is used, the code must include that annotation to be consistent with its usage. So, again, you can’t trust that it’s being used consistently.
_Side note_*:* Not to mention annotations are annoying baggage that forever follow your code. I do wish there had been a compiler flag to --ignore-unresolved-annotations
, perhaps with an argument list (like someone using Spring persistence on their interfaces, where I want the interface but not the baggage spring might bring along). I wish annotations were “comments with flair”, like javadoc or something to bypass the compiler if need be.Tomasz Krakowiak
04/20/2021, 2:28 PMVampire
04/20/2021, 2:35 PMAlan B
04/20/2021, 3:13 PM@Exhaustive
annotation used it. It’s just a gripe I have with runtime/binary annotations. 🙂 Let’s say, “aspect based” annotations are still baggage. If I want to reuse, let’s say an “entity” without hibernate, but its annotated to the hilt with hibernate or spring stuff, the code is not reusable, or you have to bring in all the dependencies that are there, even if it doesn’t ‘require’ you to enable them. Again, this is just an annoyance I have with them. It’s not “that big of a deal”. But, it’s something to take into consideration when designing a reusable, independent API/library. That’s all.