Hacker News Reader

Comment by koliber | Hacker News Reader

Another option is Exceptions. The function either does what it's supposed to, or freaks out.

You can remove the null checks and the software will raise a null pointer exception. In the first example, could raise a NotLoggedInException.

It's still a maybe function, but you have a mechanism for expressing the why-notness of the function run, as opposed to returning a generic null.

As an aside, I prefer the "Unless" model of thinking vs the "Maybe" model of thinking. It's biased towards success. It presumes that the function is most likely to do something unless a precheck fails. filterBestFriendsUnless vs maybeFilterBestFriends. getUserUnless vs maybeGetUser. If we go this far down the rabbit hole, we can assume there's always an "unless". Programs run out of memory, stacks have limited depth. There are maybe conditions for which we can not account.

View on HN

I think that's true for checked exceptions; in Typescript, I'd rather see that a function may return a null, rather than get surprised by a possible exception that's not telegraphed.

I think that's my biggest problem with exceptions. I have to rely on the doc comments to figure out whether a method can throw exceptions and which and when. And who knows if that covers all the possible exceptions from all the code that method relies on. It entirely sidesteps the type system and means I can't rely on the input/output types when using a method.

> I have to rely on the doc comments to figure out whether a method can throw exceptions

But you still have to rely on the docs to tell if a function can abort execution (say, by calling std::optional<T>::value() when there's no value). And an unhandled exception would abort just the same. Where do you see there being a difference?

> and which and when.

Maybe types don't tell you that either, you still need documentation for that.

Even worse, Maybe types cannot tell you that unless they're leaf-ish functions. Because they may call opaque functions (such as your own callbacks) for which they have no such knowledge to begin with. Thus they have to support propagating some type-erased error type... which is exactly what exceptions do.

So, again: how is the situation different?

I like the philosophy that “exceptions are for exceptional circumstances.” Not being logged in is not exceptional.

What the exceptional case is depends on the what the pre- and post-conditions of the function are. If a function assumes that the user is logged in then the user not being logged in is indeed exception. Not to say that it is good design though. That function is quite fragile like this. If it must assume that a user is logged in, then it could easily require a user to be given as an argument which will remove the whole possibility.

for a function called "getUser" it is.

Not exactly. "getUser" not having a user to get is not exceptional unless you only have logged in users. If you have logged-out users, then "getUser" should gracefully handle the case of an unknown, logged-out user (either returning null or some other sentinel value).

Returning null makes "getUser" a "maybeGetUser" function. Like said in TFA that means that any caller might need to check for nullness

Yes, no matter what, they have to check if there is an actual user if the application can have anonymous users. There’s no way around that.

Sure but only in langs wich require exception handling! Otherwise it's just hidden behaviour and explicit optional returns are better imo

I am for exceptions but it should not be used for basic control flow. Many techs will treat all exceptions as errors.

In this case, it's not being used for basic control flow. It's a prerequisite of the function that the user is logged in - and you violated that so it's an error. Returning null masks the reason why that happened. As others already said: you shouldn't even be able to call this function when your pre-requisites for calling it are violated, ideally. You can achieve that by putting this function inside some sort of object which can't be created without a logged in user. If you don't have that, you can't ask for user information.

So what I meant is that you see the exact same maybe pattern in many projects but instead of returning null there is a guard that throws an exception. I agree with the solution.

Interestingly, Python uses exceptions for basic control flow, like end of for-loop.

Semantically, Python separates Exceptions and Errors. The mechanism for throwing and catching them is the same.

Here's a quick description from somewhere on the interwebs: An error is an issue in a program that prevents the program from completing its task. In comparison, an exception is a condition that interrupts the normal flow of the program.

Then there is StopIteration, which does not fit well into either of the two above. It's a wart I've learned to treat as a beauty mark.

Well, by your definition of Exceptions and Errors, errors are something that Python, the formal language as understood by the computer, doesn't know anything about. It's a concept for humans that they can use when analysing programs. And different analyses might come to different conclusions. [0]

You could signal errors via eg returning None or False or throwing an exception. But not throwing an exception could also be an error. (Eg if your for-loop never ends, that might be an error. And that would be synonymous with StopIteration never being thrown.)

[0] Eg for a program like 'cat' it would normally be considered an error, when the file being read doesn't exist. But perhaps in my particular usage, that's expected to occur quite often, and is a normal part of my operation. You can translate this example to Python: FileNotFound might be an error, or a normal condition.

Well it uses exceptions in the case your generator is at the end, not usually at the end of a for loop because a for loop by definition iterates over a list until the list is finished.

The exception actually occurs when you call next() on a generator which cannot return any more values, or is finished, in which case `StopIteration` is usually raised.

All Python iterators raise StopIteration at the end of iteration. For-loops always use the iterator protocol. Neither generators nor lists are special in this regard.

  >>> next(iter([]))
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   StopIteration
  >>> next(iter((lambda: (yield 5) if False else None)()))
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  StopIteration

Reply on news.ycombinator.com