undefined | Better HN

0 pointsragnese5y ago0 comments

Kotlin has no mechanism to force error handling. You may suggest that we use sealed classes as return values and match on them, which is okay-ish, but suffers from two big issues:

1. You are not forced to use the result, so if you call a function for its side effects, the compiler will not warn you that you should unwrap the value. Rust and Swift do not have this issue.

2. This is extremely tedious, as you mention. But it's specific to Kotlin and not generally true as you later suggest. Haskell had monad comprehension (do notation), Scala has the same thing, Rust has the ? operator.

Also, regarding Kotlin; no library, nor the standard library, does anything other than throw unchecked exceptions on all kinds of failures. Kotlin is a step backwards, IMO.

Also PHP has checked exceptions, like Java.

0 comments

8 comments · 2 top-level

hota_mazi5y ago· 5 in thread

> Kotlin has no mechanism to force error handling.

I was referring to nullability support, which is similar to Option/Maybe, except that it's enforced by the compiler. This is pretty unique to Kotlin at the moment (honorable mention to Ceylon which offered similar support).

iainmerrick5y ago

Unique to Kotlin? Don’t Swift and TypeScript have this feature too?

Maybe it’s just the languages I’ve been working with this recently, but I think of this as something that’s breaking into the mainstream as language designers are starting to agree that it’s a good idea.

dragonwriter5y ago

> I was referring to nullability support, which is similar to Option/Maybe, except that it's enforced by the compiler.

Option/Maybe is enforced by the compiler on most languages that have it. Nullability as part of type signatures differs not because it is compiler-enforced, but because it is not nestable; it provides no equivalent of Maybe[Maybe[T]].

> This is pretty unique to Kotlin at the moment.

C# 8, Python’s typing module, Java 8 via the Nullness Checker, Sorbet for Ruby, and lots of other statically-typed languages or static-analysis packages for languages (even dynamically-typed languages) provide nullability enforcement. It's definitely not unique to Kotlin.

hota_mazi5y ago

> Option/Maybe is enforced by the compiler on most languages that have it.

It's enforced by exactly zero languages.

It's up to the developer to decide that their function should return an Option/Maybe instead of the naked value.

By definition, any library construct is NOT enforced by the compiler, because... well, it's a library construct and not a language construct.

1 more reply

ragneseOP5y ago

I like Kotlin's null most of the time, but I actually prefer Option still because every once in a while I need to nest them. You can nest Option, but not null.

valenterry5y ago

I think you should look into some more programming languages before you claim that this is unique to Kotlin. ;)

Groxx5y ago· 1 in thread

2 specifically, just to um-actually a minor detail: Rust does have this problem. This code: https://repl.it/repls/LoathsomeCompleteColdfusion

    #[must_use]
    fn get() -> i32 { 
      5
    }

    fn main() {
      get();
    }

will compile and run. It does emit a warning by default at least though:

    warning: unused return value of `get` that must be used
     --> main.rs:7:3
      |
    7 |   get();
      |   ^^^^^^
      |
      = note: `#[warn(unused_must_use)]` on by default

Without the `#[must_use]`, you won't even get that warning. Result has it, so it's common, but it's definitely not enforced. To get the Result's value though, yes - there's no way around it.

ragneseOP5y ago

You said you were picking on my second point, but you actually addressed the first.

I was specifically talking about Result and Option, which, as you mentioned, are marked must_use. It's correct that it's a warning, but I think that's good enough. You won't accidentally forget to use it.

j / k navigate · click thread line to collapse

0 comments

8 comments · 2 top-level

hota_mazi5y ago· 5 in thread

> Kotlin has no mechanism to force error handling.

iainmerrick5y ago

Unique to Kotlin? Don’t Swift and TypeScript have this feature too?

dragonwriter5y ago

> I was referring to nullability support, which is similar to Option/Maybe, except that it's enforced by the compiler.

> This is pretty unique to Kotlin at the moment.

hota_mazi5y ago

> Option/Maybe is enforced by the compiler on most languages that have it.

It's enforced by exactly zero languages.

It's up to the developer to decide that their function should return an Option/Maybe instead of the naked value.

By definition, any library construct is NOT enforced by the compiler, because... well, it's a library construct and not a language construct.

1 more reply

ragneseOP5y ago

I like Kotlin's null most of the time, but I actually prefer Option still because every once in a while I need to nest them. You can nest Option, but not null.

valenterry5y ago

I think you should look into some more programming languages before you claim that this is unique to Kotlin. ;)

Groxx5y ago· 1 in thread

2 specifically, just to um-actually a minor detail: Rust does have this problem. This code: https://repl.it/repls/LoathsomeCompleteColdfusion

    #[must_use]
    fn get() -> i32 { 
      5
    }

    fn main() {
      get();
    }

will compile and run. It does emit a warning by default at least though:

    warning: unused return value of `get` that must be used
     --> main.rs:7:3
      |
    7 |   get();
      |   ^^^^^^
      |
      = note: `#[warn(unused_must_use)]` on by default

Without the `#[must_use]`, you won't even get that warning. Result has it, so it's common, but it's definitely not enforced. To get the Result's value though, yes - there's no way around it.

ragneseOP5y ago

You said you were picking on my second point, but you actually addressed the first.

j / k navigate · click thread line to collapse