6 ms·

I’ve been trying a new thing lately: never ever use null or undefined or NaN in my own code (external libs you have to account for), instead defining my own inv

by breck 6y ago

I’ve been trying a new thing lately: never ever use null or undefined or NaN in my own code (external libs you have to account for), instead defining my own invalid types. So ‘class undefinedDivideByZero extends InvalidType’. Then just check if a value is an instance of InvalidType. Then you can create much more specific invalid types. If you have to account for 3 anyway, might as well account for N, and then create more information rich types. Is there a name for this pattern?

pwdisswordfish0 6y ago
Yes. You just reinvented exceptions.
- breck 6y ago
  Exceptions are about control flow. Nulls and undefined are about types. The flow generally continues on with the latter. So I’m wondering what the term is for when you have a whole slew of invalid types but continue on without any exception handling and instead handle it via type systems.
  - fendy3002 6y ago
    In java / C#, this is how their exception works. Indeed it is bad in performance, but you can define exception as flow. For example: try{ } catch(SQLException ex) { } catch(MathException ex) { } So it is kinda correct thay you reinvented the exception handling in java / c#, without really raising error / exception itself.
    - breck 6y ago
      Thanks that's a clear example. What I'm looking for is a name for a pattern where a function returns (typeof ExpectedType | typeof InvalidType). Say it's a pipelined compiler and you want all the passes to continue even with InvalidTypes, and then at the end of the pipeline the result is a structure of the correct shape, but there may be some "holes" filled with InvalidTypes. So one way to say it is exception types without the Try/Catch.
  - pwdisswordfish0 6y ago
    > Exceptions are about control flow. You're thinking of "try ... catch", but that's not what I'm talking about. What I'm talking about, and what I wrote, was "exceptions", i.e., objects that signify you're dealing with an exceptional case. > Nulls and undefined are about types. Anything that can be checked with instanceof, as I'm alluding to and as described in the first comment, or cross-checked by comparing a tag against constant, as in the case of node types in the DOM, is "about types". What you describe as "just check[ing] if a value is an instance of InvalidType" is a straightforward restatement of how to represent an exception and handle it. Give it extra fields with further details, etc. This is widely used, it's just not widely used in in the NodeJS world, but that has more to do with the dubious influence that people like OP have, and all the programmers who try to emulate his style.
    - breck 6y ago
      I'm only familiar with Exceptions in C++, Java, C#, Python, Javascript, etc. Are there languages where "Exceptions" are used without Try/catch? To me the term implies Exception Types/Try/Catch.
      - pwdisswordfish0 6y ago
        If this isn't clear enough at this point, it's unlikely to be worth anyone's time to explain it (again). An exception can exist and serve a purpose without ever having to be be thrown, and the thing thrown in a throw statement doesn't have to be an exception. Exceptions and "try ... catch" are completely orthogonal. The question is fundamentally... sideways.
        breck 6y ago
        Hola GPT3.
soylentgraham 6y ago
How are you serialising this value?
- breck 6y ago
  Good question! So far just context dependent. If the target is csv, generally just “”. If JSON, one of the existing types. If DSL, a discrete term from a custom grammar.
erik_seaberg 6y ago
Go calls it "errors are values", but readability is poor when every error must be handled many times instead of implicitly returning to callers.
- breck 6y ago
  ErrorValues! Thank you! This is exactly what I was looking for. Post: https://blog.golang.org/errors-are-values https://blog.golang.org/errors-are-values > but readability is poor when every error must be handled many times instead of implicitly returning to callers. I should clarify that I'm only using these types for parsing and transformation pipelines and not as a general replacement for exception handling—in other words only in places where you'd have to already worry about undefineds, nulls, and NaNs.

by breck 6y ago

pwdisswordfish0 6y ago

Yes. You just reinvented exceptions.

breck 6y ago
Exceptions are about control flow. Nulls and undefined are about types. The flow generally continues on with the latter. So I’m wondering what the term is for when you have a whole slew of invalid types but continue on without any exception handling and instead handle it via type systems.
- fendy3002 6y ago
  In java / C#, this is how their exception works. Indeed it is bad in performance, but you can define exception as flow. For example: try{ } catch(SQLException ex) { } catch(MathException ex) { } So it is kinda correct thay you reinvented the exception handling in java / c#, without really raising error / exception itself.
  - breck 6y ago
    Thanks that's a clear example. What I'm looking for is a name for a pattern where a function returns (typeof ExpectedType | typeof InvalidType). Say it's a pipelined compiler and you want all the passes to continue even with InvalidTypes, and then at the end of the pipeline the result is a structure of the correct shape, but there may be some "holes" filled with InvalidTypes. So one way to say it is exception types without the Try/Catch.
- pwdisswordfish0 6y ago
  > Exceptions are about control flow. You're thinking of "try ... catch", but that's not what I'm talking about. What I'm talking about, and what I wrote, was "exceptions", i.e., objects that signify you're dealing with an exceptional case. > Nulls and undefined are about types. Anything that can be checked with instanceof, as I'm alluding to and as described in the first comment, or cross-checked by comparing a tag against constant, as in the case of node types in the DOM, is "about types". What you describe as "just check[ing] if a value is an instance of InvalidType" is a straightforward restatement of how to represent an exception and handle it. Give it extra fields with further details, etc. This is widely used, it's just not widely used in in the NodeJS world, but that has more to do with the dubious influence that people like OP have, and all the programmers who try to emulate his style.
  - breck 6y ago
    I'm only familiar with Exceptions in C++, Java, C#, Python, Javascript, etc. Are there languages where "Exceptions" are used without Try/catch? To me the term implies Exception Types/Try/Catch.
    - pwdisswordfish0 6y ago
      If this isn't clear enough at this point, it's unlikely to be worth anyone's time to explain it (again). An exception can exist and serve a purpose without ever having to be be thrown, and the thing thrown in a throw statement doesn't have to be an exception. Exceptions and "try ... catch" are completely orthogonal. The question is fundamentally... sideways.
      - breck 6y ago
        Hola GPT3.

soylentgraham 6y ago

How are you serialising this value?

breck 6y ago
Good question! So far just context dependent. If the target is csv, generally just “”. If JSON, one of the existing types. If DSL, a discrete term from a custom grammar.

erik_seaberg 6y ago

Go calls it "errors are values", but readability is poor when every error must be handled many times instead of implicitly returning to callers.

breck 6y ago
ErrorValues! Thank you! This is exactly what I was looking for. Post: https://blog.golang.org/errors-are-values https://blog.golang.org/errors-are-values > but readability is poor when every error must be handled many times instead of implicitly returning to callers. I should clarify that I'm only using these types for parsing and transformation pipelines and not as a general replacement for exception handling—in other words only in places where you'd have to already worry about undefineds, nulls, and NaNs.