Java 8’s new Optional type doesn't solve anything

Post by aclissold » Mon, Oct 26, 2015, 3:19 PM UTC

Post by valarauca1 » Mon, Oct 26, 2015, 3:26 PM UTC

Gankro wrote: post #93

krisdol wrote: post #80

Earlier quoted context omitted.

>Gonna have your function return an Err if an internal invariant is broken? Absolutely you should return an error. Whether the caller wants to panic or handle it or print unicorns should be left up to the caller, not your function. Functions should not be expected to tear down the thread in case of an error. Nothing that panics should belong anywhere in exported code

This seems a bit too unpragmatic. Would you also require the user to explicitly handle: * Index out of bounds on every array op * Integer overflow on every arithmetic op * OOM on every allocating op Maybe if you're writing an ironclad RTOS for a critical system without any good redundancy? Otherwise these are such pervasive operations that most have accepted that they're not worth handling everywhere they happen. Req…

Post by craigching » Mon, Oct 26, 2015, 3:27 PM UTC

MereInterest wrote: post #75

w23j wrote: post #38

Earlier quoted context omitted.

I am not sure I understand. I guess you are either saying (A) to treat every return type as possibly null or (B) to use your judgment when doing null checks of return types. In case of (A): Do you want to write null-checks for methods like String.toUpperCase() or for user.getLastName() ? That would lead to a lot of bloated, dead code. Also do you want to write error handling for all these cases you know can never hap…

I would say that every return type that can be NULL should be checked for being NULL. In C++, this is possible, because you most functions are return-by-value or return-by-reference. This leaves only return-by-pointer that need to be explicitly checked. In Java, all functions that do not return primitives are return-by-pointer, and are therefore nullable. This, as you mentioned, makes it infeasible to apply null-chec…

Post by BorgHunter » Mon, Oct 26, 2015, 3:31 PM UTC

jrockway wrote: post #109

tel wrote: post #68

Earlier quoted context omitted.

> That said, it's pretty rare to need exactly 0 or 1 of something. That's interesting and sort of hard to agree with. I think uniqueness is very often desirable and very often paired with a lack of certainty about existence. "Does a user with this identity exist?" certain is handled properly as a 0-or-1 question, e.g..

Is your method "getUserIfItExists(username)" or "doesUserExist(username)"?

    def getUserGreeting(userDao: UserDAO)(username: String): String =
      userDao.getOptionalUser(username) match {
        case Some(user) => "Hello, " + user.getFullName
        case None => "Not logged in"
      }

    def getUserGreeting(userDao: UserDAO)(username: String): String =
      if(userDao.doesUserExist(username)) match {
        "Hello, " + userDao.get(username).getFullName
      } else {
        "Not logged in"
      }

Post by pcwalton » Mon, Oct 26, 2015, 3:33 PM UTC

markus2012 wrote: post #66

krisdol wrote: post #45

Earlier quoted context omitted.

>tl;dr: Haskell, Rust, et al. put the burden on the compiler. Java puts the burden to ensure safety on the programmer. (As can be witnessed in your snippet.) Actually, (much to my disappointment as I'm just learning rust) you can just take an Option or Result and .unwrap() and the compiler won't complain at you for not checking it. For such a "safe" strongly-typed language, I'm surprised that so much new rust code do…

I completely agree. unwrap() is a huge mistake in Rust. There are brilliant ideas implemented in Rust (primarily the borrow checker) but their advantages seem to be wiped out by the kludge of unwrap.