when should I be using `error()` over `throw Illeg...

# getting-started

[William Reed]

when should I be using error() over throw IllegalStateException ? is error always more idiomatic?

[Joffrey]

I personally use error() all the time. It's more idiomatic and more concise. The only reason to use throw IllegalStateException(...) explicitly is if you want to give it a cause, which error() doesn't support

[ephemient]

also check(x) { msg } instead of if (!x) error(msg) and checkNotNull(x) { msg } instead of x ?: error(msg)

[ephemient]

or `require`/`requireNotNull` for IllegalArgumentException

[ephemient]

I find it rare to need error or `throw IAE`/`ISE`

[Joffrey]

and checkNotNull(x) { msg } instead of x ?: error(msg)

I agree with everything except this. When I have a chain of operations on a collection, or a sequence of function calls etc, I find it much more readable to use an elvis at the end rather than wrapping in `checkNotNull`:

list.map { ... }.firstOrNull { ... } ?: error("...")

foo.bar?.baz()?.stuff() ?: error("...")

[ephemient]

I'd tend to use

val result = list.map { ... }.firstOrNull { ... }
return checkNotNull(result) { "..." }

or similar. whether you use checkNotNull or ?: it doesn't really chain well

[Joffrey]

Depends on what you call chaining. To me the important aspect is that the flow goes left to right. I don't mind that ?: is not ..

[ephemient]

checkNotNull(...).foo
(... ?: error()).foo

is awkward either way, if ... is a multi-line expression

[Joffrey]

Ah I see what you mean. Well, usually the elvis and the error come last thanks to safe calls. I never nest expressions like (... ?: error()) in a chain. If I need this kind of expressions I extract them to functions

[Stephan Schröder]

assuming ... is a multi-line expression, I tend to use

...?.foo ?: error("abc")

but of course you could do:

val f = ...?.foo
checkNotNull(f)

[ephemient]

sometimes that doesn't have the same result, e.g.

checkNotNull(x.nullable1()).nullable2()

!=

x.nullable1()?.nullable2() ?: error()

[Stephan Schröder]

true, it's a pattern to assert that a non-null f could be aquired. which is almost always what I want.

[Joffrey]

sometimes that doesn't have the same result

Right, but in the case you describe, I'd probably extract the first part to a separate non-nullable extension.

[Elena van Engelen]

checkNotNull acutally throws IllegalStateException and not IllegalArgumentException. You may find this article helpfull about these built in functions:
https://medium.com/@elenavanengelen/kotlin-tips-and-tricks-you-may-not-know-3-built-in-assertions-d26540ccb2e0

[Joffrey]

Yes, the question was about throwing IllegalStateException here, and we compared it with error(), which also throws IllegalStateException, so all good 😉

[Elena van Engelen]

I think check/require functions are cleaner for checking conditions than doing conditions manually and then calling error(). However in some cases error() is more approriate, for example in when statements.

[Elena van Engelen]

here is an example

fun processPaymentMethod(paymentMethod: String) {
    when (paymentMethod) {
        "CreditCard" -> println("Processing payment with Credit Card")
        "PayPal" -> println("Processing payment with PayPal")
        else -> error("Unsupported payment method: $paymentMethod")
    }
}

[Joffrey]

I don't think error supports lambdas, it doesn't really make sense since we're using the message 100% of the time

[Joffrey]

Ah, I realized it's an example of bad usage

[Elena van Engelen]

yea i copy pasted the wrong example, i'll update that

[Joffrey]

I think check/require functions are cleaner for checking conditions than doing conditions manually and then calling error()

Yeah that's what we were trying to refine in the discussion above. Which cases more specifically are more suited for one or the other. As I mentioned, I like how the elvis flows with error() in some chained cases. For single-condition checks, the dedicated `check`/`require` functions are more appropriate indeed.

[Elena van Engelen]

yes its a matter of preference , i prefer asigning the end value and then do a check... or require... . like mentioned above by ephemient

[Elena van Engelen]

makes it more explicit + readable. also i find it more maintainable as the chain might change over time, thus it helps to separate the null check from it.