7 ms·
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
by koliber 3y ago
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.
- pavel_lishin 3y agoI 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.
- Sakos 3y agoI 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.
- dataflow 3y ago> 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?
- AtNightWeCode 3y agoI am for exceptions but it should not be used for basic control flow. Many techs will treat all exceptions as errors.
- eru 3y agoInterestingly, Python uses exceptions for basic control flow, like end of for-loop.
- callamdelaney 3y agoWell 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.
- oasisaimlessly 3y agoAll 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
- koliber 3y agoSemantically, 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.
- 3y ago
- nnnnico 3y agoSure but only in langs wich require exception handling! Otherwise it's just hidden behaviour and explicit optional returns are better imo
- jagged-chisel 3y agoI like the philosophy that “exceptions are for exceptional circumstances.” Not being logged in is not exceptional.
- _ZeD_ 3y agofor a function called "getUser" it is.
- withinboredom 3y agoNot 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).
- _ZeD_ 3y agoReturning null makes "getUser" a "maybeGetUser" function. Like said in TFA that means that any caller might need to check for nullness
- withinboredom 3y agoYes, 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.
- Lvl999Noob 3y agoWhat 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.