3 ms·

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 wor

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.

skwirl 6y ago
>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.
dkjaudyeqooe 6y ago
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?
- Graffur 6y ago
  > If they're the highest level why didn't the other 6 layers handle it? I would have the same question.
larzang 6y ago
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.
TeMPOraL 6y ago
> 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.

skwirl 6y ago

>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.

dkjaudyeqooe 6y ago

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?

Graffur 6y ago
> If they're the highest level why didn't the other 6 layers handle it? I would have the same question.

larzang 6y ago

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.

TeMPOraL 6y ago

> 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.