What’s the correct way to signal that a property getter failed to execute? I know kotlin prefers se...

# announcements

[Patrick Ramsey]

What’s the correct way to signal that a property getter failed to execute? I know kotlin prefers sealed class result types to exceptions, but I can’t think of another good way to communicate to the caller that a property getter failed except to return null, which isn’t always a good option.

[Patrick Ramsey]

Or is the answer basically, “if your property hides complex logic that might fail, it should probably just be a method”?

[CLOVIS]

Essentially:
• exceptions for impossible cases, programming error
• null when the failure is expected and you don't really care why it failed
• sealed classes when you need to know why

Depending on how complex your thing is, it might be better to make it a method but I don't think it changes the problem that much

[Patrick Ramsey]

well I mean

[Patrick Ramsey]

“sealed classes when you need to know why” doesn’t fit well with a getter

[Patrick Ramsey]

because now your property is a SomethingResult<String>

[Patrick Ramsey]

instead of a String

[Patrick Ramsey]

which at least to me feels awkward

[Patrick Ramsey]

but maybe it’s just me! It’s just that it doesn’t feel very much like a property at that point, since it’s basically clearly marked as a return value

[Patrick Ramsey]

also means the implementation can’t change in the future

[Patrick Ramsey]

also only tangentially relevant, but it seems worth mentioning that lazy { } has a useful property which is that if the initializer throws, then it reruns the next time. afaict there’s no way to get this behavior without throwing (or avoiding using lazy { } )

[Zach Klippenstein (he/him) [MOD]]

Or is the answer basically, “if your property hides complex logic that might fail, it should probably just be a method”?

Yea that’s it

[Patrick Ramsey]

righto.

[Patrick Ramsey]

thanks.