My previous problem, but since many people suggest NOT using exception, I asked the non-exception ve...

# random

[Jason5lee]

My previous problem, but since many people suggest NOT using exception, I asked the non-exception version.

Which of the following is your preferred way to define error?
1.

sealed class QueryResult {
    data class Success(...) : QueryResult()
    object NotFound : QueryResult()
    object SomeOtherError : QueryResult()
}

// API Code
when(result) {
    is QueryResult.Success -> HttpResponse(200, "...")
    QueryResult.NotFound -> HttpResponse(404, ...)
    ...
}

2.

sealed class QueryResult {
    data class Success(...) : QueryResult()
    data class Error(val status: HttpStatus, ...) : QueryResult()
}

// API Code
when (result) {
    is QueryResult.Success -> HttpResponse(200, ...)
    is QueryResult.Error -> HttpResponse(result.status, ...)
}

The second way is more convenient but the Error type is coupled with the HTTP protocol.

[ephemient]

I would normally use a pattern more like

sealed class QueryResult {
    data class Success(...) : QueryResult()
    sealed class Failure : QueryResult() {
        object NotFound : Failure()

[Rob Elliot]

Coupling your data query domain to a particular wire protocol seems to me to be mixing concerns in a way that's liable to bite you long term.

Perhaps with an extension function:

fun QueryResult.status(): HttpStatus = when (this) {
  is QueryResult.Success -> OK
  is QueryResult.NotFound -> NOT_FOUND
  is QueryResult.SomeOtherError -> SERVER_ERROR
}

I like extension functions for translations between concerns, where neither should know about the other.