Hacker News Reader

Comment by noir_lord | Hacker News Reader

If you have nulls (or nullable types) then you end up checking for them everywhere (in every codebase I've seen anyway - keeping them on the boundaries only works if that's practical and the language always does it for it's standard libraries etc).

Additionally you can no longer say Thing is Thing, it's always Thing or null - which results in special handling

if (foo === null){} everywhere and when you don't boom NullPointerException.

Exceptions cause problems in other ways (especially when they are allowed to escape up the stack), business logic shouldn't be handling FileNotFoundException that was thrown 6 layers away.

View on HN

>Exceptions cause problems in other ways (especially when they are allowed to escape up the stack), business logic shouldn't be handling FileNotFoundException that was thrown 6 layers away.

So instead all 6 layers should have to know about it in addition to business logic? In most cases you can't really ignore the fact that a file didn't exist in your business logic.

> business logic shouldn't be handling FileNotFoundException that was thrown 6 layers away

No, that's the job of whoever requests a file to be read. But what they may do in reaction to this, or discovering the file is empty, or has malformed data, is to throw a DataUnavailable exception, a subtype of RequestError. This is something appropriate places of the business logic up the stack may be interested in. Maybe some code few layers up the call stack can recover from DataUnavailable by attempting to pull from an alternate data source. Maybe not. Maybe that too will fail. Further up still, something else will intercept RequestError and report a problem to the user.

But, unlike with Result types, only those three places in this piece of business logic have to ever care about some file not being read. Everything else can just assume the operation succeeded.

Exception types follow the same rules as "regular" user-defined types: they're relevant in a subsection of a program, and shouldn't propagate beyond that subsection.

So what's your proposed alternative that doesn't involve checking? Option-style wrappers enforce consistent checking and handling, but so do explicitly nullable type signatures. At some point you're going to need to know whether you have data or not, and that requires checks.

That's an argument for exceptions. If they shouldn't be handling it they shouldn't be catching it. If they're the highest level why didn't the other 6 layers handle it?

It's easier to be adaptive with error handling with exceptions, and who's going to (correctly) test for all possible errors on every call?

> If they're the highest level why didn't the other 6 layers handle it?

I would have the same question.

Reply on news.ycombinator.com