Proposal - Amend Test Specification / Error Handling

[TotalTechGeek]

Background

We currently have a test specification format here: https://github.com/json-logic/.github/blob/main/TEST_FORMAT.md

A test case should be a JSON object with the following fields:

• description (string, required): A short, human-readable description of the test case that explains its purpose.
• rule (any, required): The JSON Logic rule to be tested.
• data (any, required): The input data that the rule will evaluate against.
• result (any, required): The expected result after evaluating the rule with the provided data.

any refers to any valid RFC8259 value.
string refers to strings in RFC8259.

The test cases are stored as an array of these objects, allowing for multiple tests in a single file.

This is great for positive testing; but we might want to amend our specification to make things simple for negative testing, as well.

Positive Testing - Checking that functionality behaves as expected.
Negative Testing - Checking that functionality fails as expected.

Proposal

I'd like to amend the test format to essentially be:

type Base = { description: string,  rule: any, data: any }
type Error = { type: string }
type Format = Base & ({ result: any } | { error: Error })

Essentially, every rule has:

• description (string, required): A short, human-readable description of the test case that explains its purpose.
• rule (any, required): The JSON Logic rule to be tested.
• data (any, required): The input data that the rule will evaluate against.

But the rule must have either:

• result (any, required): The expected result after evaluating the rule with the provided data.

or

• error (Error, required) - Communicates that it is expected that the logic will fail due to a hard error. This object must partial match against the error emitted.

But not both.

This would potentially allow us to define a test case like:

[
  {
        "description": "Panic with an error emitted from an operator",
        "rule": { "/": [1, 0] },
        "error": { "type": "NaN" },
        "data": null
   }
]

I'm going to do something dumb, and propose two options. Please vote on each independently.

**Option A (Hard Errors / Exceptions)**

With this proposal, we will define that errors should bubble up the AST and halt execution.

Implementations will be responsible for deciding how they want to emit and represent hard errors.

With this proposal, we will introduce a few operators:

Operator	Description
throw	A unary operator that throws an error. If it receives an error object, like in try, it will throw that.
try	An operator that can "catch" exceptions that have bubbled up the AST. This operator will substitute the context for the error on the 2nd element forward. This operator will be responsible for converting the exception into a JSON Object to be placed into context. At a minimum, the object must have { "type": "type" }

Test Cases

throw

Expand

[
    {
        "description": "Throws hello as an error",
        "rule": { "throw": "hello" },
        "data": null,
        "error": { "type": "hello" }
    },
    {
        "description": "Throwing NaN produces an error object or measured equivalent (equivalence class test)",
        "rule": { "throw": "NaN" },
        "data": null,
        "error": { "type": "NaN" }
    },
    {
        "description": "Can throw an error object",
        "rule": { "throw": { "val": "x" } },
        "data": { "x": { "type": "Some error" }},
        "error": { "type": "Some error" }
    }
]

try

Expand

[
    "# Collection of Tests for Try",
    {
        "description": "Coalesce an error",
        "rule": { "try": [{ "throw": "Some error" }, 1] },
        "result": 1,
        "data": null
    },
    {
        "description": "Coalesce an error emitted from an operator",
        "rule": { "try": [{ "/": [0, 0]}, 1] },
        "result": 1,
        "data": { "hello": "world" }
    },
    {
        "description": "Try is variadic",
        "rule": { "try": [{ "throw": "Some error" }, { "/": [0, 0] }, 2] },
        "result": 2,
        "data": null
    },
    {
        "description": "Panics if none of the values are valid",
        "rule": { "try": [{ "throw": "Some error" }, { "throw": "Some other error" }] },
        "error": { "type": "Some other error" },
        "data": null
    },
    {
        "description": "Panics if none of the values are valid (2)",
        "rule": { "try": [{ "throw": "Some error" }, { "/": [0, 0] }] },
        "error": { "type": "NaN" },
        "data": null
    },
    {
        "description": "Panics if none of the values are valid (3)",
        "rule": { "try": [{ "/": [0, 0] }, { "/": [1, 0] }, { "/": [2, 0] }] },
        "error": { "type": "NaN" },
        "data": null
    },
    {
        "description": "Panics when the only argument is an error",
        "rule": { "try": { "throw": "Some error" } },
        "error": { "type": "Some error" },
        "data": null
    },
    {
        "description": "Panic with an error emitted from an operator",
        "rule": { "try": [{ "/": [1, 0] }] },
        "error": { "type": "NaN" },
        "data": null
    },
    {
        "description": "Panic within an iterator",
        "rule": { "map": [[1, 2, 3], { "try": [{ "/": [0,0] }] }] },
        "error": { "type": "NaN" },
        "data": null
    },
    {
        "description": "Panic based on an error emitted from an if",
        "rule": { "try": [{ "if": [{"val": ["user", "admin"]}, true, { "throw": "Not an admin" }] }] },
        "data": { "user": { "admin": false } },
        "error": { "type": "Not an admin" }
    },
    {
        "description": "Try can work further up the AST with Exceptions",
        "rule": {
            "try": [{
                "if": [
                    true,
                    { "map": [[1,2,3], {"/": [0, 0] }]},
                    null
                ]
            }, 10]
        },
        "result": 10,
        "data": null
    },
    {
        "description": "The context switches for the try coalescing to the previous error",
        "rule": {
            "try": [
                { "throw": "Some error" },
                { "val": "type" }
            ]
        },
        "result": "Some error",
        "data": null
    },
    {
        "description": "The context switches for the try coalescing to the previous error (2)",
        "rule": {
            "try": [
                { "if": [true, { "throw": "Some error" }, null] },
                { "val": "type" }
            ]
        },
        "result": "Some error",
        "data": null
    },
    {
        "description": "The context switches for the try coalescing to the previous error (3)",
        "rule": {
            "try": [
                { "throw": "A" },
                { "throw": "B" },
                { "val": "type" }
            ]
        },
        "result": "B",
        "data": null
    },
    {
        "description": "Error can pull from an error object",
        "rule": {
            "try": [{ "throw": { "val": "x" } }, { "val": "type" }]
        },
        "data": { "x": { "type": "Some error" }},
        "result": "Some error"
    },
    {
        "description": "Try can work further up the AST with Exceptions, and return the error",
        "rule": {
            "try": [{
                "if": [
                    true,
                    { "map": [[1,2,3], {"/": [0, 0] }]},
                    null
                ]
            }, { "val": "type" }]
        },
        "result": "NaN",
        "data": null
    },
    {
        "description": "Handles NaN Explicitly",
        "rule": {
            "try": [
                { "if": [{ "/": [1, { "val": "x" }] }, { "throw": "Some error" }, null] },
                {
                    "if": [{ "===": [{ "val": "type" }, "NaN"]}, "Handled", { "throw": { "val": [] } }]
                }
            ]
        },
        "result": "Handled",
        "data": { "x": 0 }
    },
    {
        "description": "Did not NaN, so it errored",
        "rule": {
            "try": [
                { "if": [{ "/": [1, { "val": "x" }] }, { "throw": "Some error" }, null] },
                { "if": [{ "===": [{ "val": "type" }, "NaN"]}, "Handled", { "throw": { "val": [] } }] }
            ]
        },
        "error": { "type": "Some error" },
        "data": { "x": 1 }
    }
]

---

**Option B (Soft Errors)** -- (Withdrawn)

This option has been withdrawn.

With this proposal, we will recognize two forms of errors:

• Hard Errors, errors that should halt the logic execution and are not handled within the AST.
• Soft Errors, errors that are returned from operators as data, in the form of a JSON Object with a key error. These errors can be handled in the AST. (NaN is an example of a Soft Error)

For soft errors, implementations may choose to create equivalence classes, to define a language construct as being equal to a soft error. (NaN can be made equivalent to { "error": "NaN" })

Implementations will be responsible for deciding how they want to emit and represent hard errors.

With this proposal, we will introduce a few operators:

Operator	Description
error	A unary operator that returns a single key JSON Object with the key "error", with the first argument being the value. Implementations may choose to substitute the return value for an equivalent language construct, as long as it's handled the exact same way.
try	A coalescing operator similar to ?? and or with short-circuit behavior. It will coalesce to the first non-error argument, or it will panic.** (Do we want this to return the last argument instead? If so, I'll reintroduce panic)

Test Cases

error

Expand

[
    {
        "description": "Creates an error object",
        "rule": { "error": "hello" },
        "data": null,
        "result": { "error": "hello" }
    },
    {
        "description": "NaN creates an error object or measured equivalent (equivalence class test)",
        "rule": { "error": "NaN" },
        "data": null,
        "result": { "error": "NaN" }
    }
]

try

Expand

[
    "# Collection of Tests for Try",
    {
        "description": "Coalesce an error",
        "rule": { "try": [{ "error": "Some error" }, 1] },
        "result": 1,
        "data": null
    },
    {
        "description": "Coalesce an error emitted from an operator",
        "rule": { "try": [{ "/": [0, 0]}, 1] },
        "result": 1,
        "data": { "hello": "world" }
    },
    {
        "description": "Coalesce an error pulled from context; errors are just data.",
        "rule": { "try": [{ "val": "x" }, 1]},
        "data": { "x": { "error": "Some error" }},
        "result": 1
    },
    {
        "description": "Panics if none of the values are valid",
        "rule": { "try": [{ "error": "Some error" }, { "error": "Some other error" }] },
        "error": true,
        "data": null
    },
    {
        "description": "Panics if none of the values are valid (2)",
        "rule": { "try": [{ "error": "Some error" }, { "/": [0, 0] }] },
        "error": true,
        "data": null
    },
    {
        "description": "Can promote a soft error to a hard error",
        "rule": { "try": { "error": "Some error" } },
        "error": true,
        "data": null
    },
    {
        "description": "Panic with an error emitted from an operator",
        "rule": { "try": [{ "/": [1, 0] }] },
        "error": true,
        "data": null
    },
    {
        "description": "Panic with an error pulled from context",
        "rule": { "try": [{ "val": "x" }] },
        "error": true,
        "data": { "x": { "error": "Some error" } }
    },
    {
        "description": "Panic within an iterator",
        "rule": { "map": [[1, 2, 3], { "try": [{ "/": [0,0] }] }] },
        "error": true,
        "data": null
    },
    {
        "description": "Panic based on an error emitted from an if",
        "rule": { "try": [{ "if": [{"val": ["user", "admin"]}, true, { "error": "Not an admin" }] }] },
        "data": { "user": { "admin": false } },
        "error": true
    }
]

Related Materials

For Option A:

• https://github.com/json-logic/json-logic-engine/blob/9d4f8bf8b3e94da1d47bf35862145484fd4b717a/suites/plus.json

An example of how the numeric tests would work. They cause an error.

For Option B:

• https://github.com/json-logic/json-logic-engine/blob/46e6e5f39761e0f00d613cfddb243ec08bd6f781/suites/plus.json

Additional Decisions (Both Proposals)

• NaN is an Error. In Option A, this is a Hard Error. In Option B, this is a Soft Error.
• Division by Zero produces NaN

[TotalTechGeek]

Something to think about before I undraft this:

The following rule gives me pause, and we could decide to avoid these cases,

{ "*": ["h", 5] }

This guy would emit NaN in my implementation, which I'd be happy to detect as an error, the problem is that this "error" doesn't halt logic execution.

Should errors be expected to halt / prevent logic execution? I would think so, and if so, I think that helps us set guidelines for what error boundaries we want to test for.

[codetiger]

This triggers another proposal for error classifications and implementation behavior for errors. But in general, I support having an error field in test format.

+1

[TotalTechGeek]

Some excerpts from another dicussion over JSON Logic error behaviors.

From @gregsdennis
https://github.com/orgs/json-logic/discussions/21#discussioncomment-11871756

How are we going to represent NaN? Input and output is JSON, which has no such construct. Perhaps it's better for the evaluator to just error using the mechanisms of its language/framework (e.g. exceptions for .Net).

From @dslmeinte
https://github.com/orgs/json-logic/discussions/21#discussioncomment-11871760

Or introduce an explicit representation of an error, which can be “bubbled up”.

From me

(I think we'd encounter significant pain if some implementations Hard Errored while others Soft Errored -- what I meant by consistency. So if we defined that coercion of an array is a soft error, I think it should be represented that way across all implementations)

We need to decide if JSON Logic will support the concept of "Soft Errors" which doesn't halt execution and instead emit some value, or if errors will exclusively halt termination.

I can see arguments both ways on numeric conversion.

How do we handle { "/": [0, 0] }, especially if we're precision agnostic.

It'd be a bit messy if we allowed NaN as a return type given that we can't encode NaN natively in JSON .

[gregsdennis]

The only problem I can see with the soft error is working out what value to emit. It needs to be understood that this value will end up being used as an input somewhere, whether we intend that or not. Maybe that can be a good thing, though.

[TotalTechGeek]

It'd be the first construct in JSON Logic that cannot be implicitly represented in JSON 🫤, and it comes with questions about how you could check for it / whether it is truthy or falsy by default.

I think I can see how it could be useful for custom operators, but it's a bit messier / requires a bit more to be added to Core to make it work 🤔

[gregsdennis]

We should avoid non-JSON until it solves a problem we can't otherwise solve.

[TotalTechGeek]

To be clear -- I absolutely agree. I don't really want to consider something outside of JSON's data model for core constructs.

I'm hesitant on the concept of soft errors bc of this.

The best idea I currently have is to represent soft errors as JSON objects, perhaps with a designated key.

I'm going to tinker this weekend with it and see how it "feels"

[TotalTechGeek]

I have an idea I'll tinker with this weekend w/r/t "soft errors", and how to make them viable across implementations.

I'm personally not really leaning heavily towards either approach.

I believe deciding everything is a Hard Error would be much simpler from a specification perspective, but potentially reduces capability / efficiency from an AST perspective.

--

Keep in mind that this is half-baked and I'm merely playing with the idea for soft-errors to see if there's any viability in this.

Right now, the idea I'm contemplating is some sort of error operator & allowing test implementers to set up equivalence classes.

engine.addMethod('error', ([type]) => {
  // Implementations could choose to substitute values that make sense
  if (type === 'NaN') return Number.NaN
  
  // literally returns an object; 
  // it could be best if this was some stable reference for easier comparison, rather than a new
  // object each time.
  return { error: type }
})

And to check for this soft error, which is actually a data value, one could do:

[
  {
    "description": "Checks if 0 / 0 produces NaN",
    "rule": { "/": [0, 0] },
    "result": { "error": "NaN" },
    "data": null
  },
  {
    "description": "Adding 1 to NaN",
    "rule": { "+": [1, { "error": "NaN" }] },
    "result": { "error": "NaN" },
    "data": null
  }
]

In this case, there'd be an equivalence established in the test runner between { "error": "NaN" } and NaN for this implementation. (And to be clear, we're not executing JSON Logic on the result)

Implementations / Architectures without a native NaN concept would have to pass the JSON Object around.

There is a question of truthiness, in JS, NaN is falsey, while the error object would be truthy, so we'd need to decide on whether these soft errors are truthy or falsy.

On the surface, it seems like this could be alright, but what happens when I pass in a context with:

{
  "x": { "error": "NaN" }
}

And call { "val": "x" } 🤔

Could this ever lead to unintended behavior, or work in unintuitive ways?

There are mental models where I could see this working out fine.. but also ones where this could cause problems.

[TotalTechGeek]

@JTeeuwissen said:
https://github.com/orgs/json-logic/discussions/21#discussioncomment-11873830

In which case a try(catch) operator could be introduced to try something else when the first evaluation fails.
Which could be used to turn a hard error into a soft one.

(Funnily enough, I actually commited an experiment on that shortly before: json-logic/json-logic-engine@5d5c38d)

[TotalTechGeek]

I think I might experiment with improving the coalescing operator to handle soft errors, in which case,

{ "??": [{ "+": [{ "val": "x" }, { "val": "y" }] }, 42] }

Would fall back to 42 if x was "hello" or something strange.

This reminds me of .unwrap_or in Rust 🤔

[TotalTechGeek]

So I've been experimenting with the soft-error construct and... it's actually seemingly decent. It's OK. I think there's an argument for soft-error viability.

What I've implemented:

• I've introduced an operator called error. It is a unary operator that accepts a type. It returns a single key JSON object in the form of { error: type }.
  (If implementations wish to, they can establish equivalence classes between these error objects and some other construct in their architecture. For example, I've specified that NaN is the same as { "error": "NaN" }. As long as it's handled the same)

• Soft Errors are just data; they're an object with an error property on it.

• Errors are currently defined to be truthy, though we can tweak this.

• I've tweaked the coalescing operator (??) to handle both nulls and errors. This allows us to define fallback behavior if an error occurs. This allows JL to handle try/catch-like behavior. I've introduced try to coalesce errors.

• I have a panic operator that accepts a single argument, and if it is an error, will turn it into a hard error and halt AST execution, otherwise it will pass it through. I don't have strong feelings for or against this operator, it was an experiment.

The coalescing allows us to do something like

{ "try": [{ "+": [{ "val": "x" }, 1]}, 42] } // Falls back to 42 if val x cannot coerce to a number

+ Tests

[
    {
        "description": "Addition with NaN",
        "rule": { "+": [{ "error": "NaN" }, 1] },
        "result": { "error": "NaN" },
        "data": null
    },
    {
        "description": "Addition with string produces NaN",
        "rule": { "+": ["Hey", 1] },
        "result": { "error": "NaN" },
        "data": null
    },
    {
        "description": "Addition with Array produces NaN",
        "rule": { "+": [[1], 1] },
        "result": { "error": "NaN" },
        "data": null
    },
    {
        "description": "Addition with Array from context produces NaN",
        "rule": { "+": [{ "val": "x" }, 1] },
        "result": { "error": "NaN" },
        "data": { "x": [1] }
    },
    {
        "description": "Addition with Object produces NaN",
        "rule": { "+": [{ "val": "x" }, 1] },
        "result": { "error": "NaN" },
        "data": { "x": {} }
    },
    {
        "description": "Plus Operator with Single Operand, Invalid String Produces NaN",
        "rule": { "+": "Hello" },
        "result": { "error": "NaN" },
        "data": null
    },
    {
        "description": "Plus Operator with Single Operand, Array Input Produces NaN",
        "rule": { "+": [[1]] },
        "result": { "error": "NaN" },
        "data": null
    }
]

Misc Error Tests

[
    "# Some error tests",
    {
        "description": "NaN is Truthy",
        "rule": { "!!": { "error": "NaN" } },
        "result": true,
        "data": null
    },
    {
        "description": "Arbitrary error is Truthy",
        "rule": { "!!": { "error": "Some error" } },
        "result": true,
        "data": null
    },
    {
        "description": "Coalesce an error",
        "rule": { "try": [{ "error": "Some error" }, 1] },
        "result": 1,
        "data": null
    },
    {
        "description": "Coalesce an emitted error",
        "rule": { "try": [{ "+": [{ "val": "hello" }]}, 1] },
        "result": 1,
        "data": { "hello": "world" }
    },
    {
        "description": "Errors are just data",
        "rule": { "try": [{ "val": "x" }, 1]},
        "data": { "x": { "error": "Some error" }},
        "result": 1
    }
]

I have more tests in here: https://github.com/json-logic/json-logic-engine/pull/42/files

[gregsdennis]

I prefer ?? to respect the error and we use a try/catch to ignore it. This seems more in line with modern programming languages to me.

[TotalTechGeek]

I'll put @gregsdennis down as 0.9 w/ try, error and panic on Soft Errors.

[TotalTechGeek]

I'm also going to put myself as a +0.9 on soft errors.

[codetiger]

+1 for soft errors and ‘try’ operator name sounds more natural.

[TotalTechGeek]

[
    {
        "description": "Any division by zero should return NaN",
        "rule": { "/": [1, 0] },
        "result": { "error": "NaN" },
        "data": null
    },
    {
        "description": "Any division by zero should return NaN (2)",
        "rule": { "/": [8, 2, 0] },
        "result": { "error": "NaN" },
        "data": null
    }
]

I think I also want to define any division by zero as a NaN-like error, since in a handful of decimal implementations (like in C#), division by zero would result in an error.

While IEEE754 defines this as Infinity, I'm in favor of deviating from this in favor of precision agnosticism.

[JTeeuwissen]

Before it is snowed under in a comment section, I propose a somewhat different approach:

For the testing data

type Base = { description: string,  rule: any, data: any }
type Format = Base & ({ result: any } | { error: Error })
type Error = { description: string,  path: string[] }

Where each rule either returns a result, or an error, to be delivered in a language fitting manner (exceptions, monads, etc.)

The difference between data and error implies that they are handled differently from each other, error not simply being data in a special format (which would not play nice with operators using objects as input).
Instead, errors would propagate upwards to a try catch operator. Making any handling explicit, without placing an error checking burden on each operator. Effectively defaulting to "hard errors" with an opt out.

[TotalTechGeek]

Does NaN hard-error? If so, +0.5 on this guy from me. I'm assuming a self +1 for your proposal

If it doesn't hard error, I need clarification on NaN to vote.

Though some syntax & proposed tests for the try/catch might be necessary. I will note a caveat of hard errors is that it might be more difficult for languages like Go and Rust to implement them, as it's a bit less language idiomatic for them (in JS, I can rely on existing scaffolding to pull this off).

[JTeeuwissen]

Does NaN hard-error?

As far as I'm concerned, it does. But I'll admit that most languages do handle Nan and Infinity different from other exceptions.

Another option would be to do something like c# AllowNamedFloatingPointLiterals and just store them as strings

Perhaps hard error is not the right term though, as it would be possible to catch (as opposed to a panic like in rust)

I will note a caveat of hard errors is that it might be more difficult for languages like Go and Rust to implement them

I think go uses tuples for error results and rust can use Result (like the Haskell Either)

[TotalTechGeek]

Maybeexcept or interrupt is a better term. I think we'll try to weigh community sentiment on each approach and figure out which we'll proceed with, and I'll rewrite the root proposal.

[TotalTechGeek]

At this phase, it appears that sentiment is leaning towards soft errors. I'm going to leave this open for a bit longer to offer folks time to vote on each. (You can vote independently on each solution, and it's okay to be comfortable with both!)

[TotalTechGeek]

At this point, I'm going to revise the root proposal in favor of soft errors, but if there ends up being more support for hard errors, I can adjust accordingly.

[TotalTechGeek]

I'm voting +1 on Option A, +0.5 on Option B.
@JTeeuwissen I'm assuming you're a +1 on Option A.

[dslmeinte]

Time is a scarce resource for me, unfortunately, and I don't have any to go contextually in-depth.

In general, I favor FP-style languages. This means (a.o. things): referential integrity, substitution model, algebraic thinking, homoiconeity, “monadic thinking”, no side-effects, stateless, static typing. As a result, I like to avoid that operations error out by throwing an implementation-specific error/exception. Since a while, I've liked the idea of “errors as ordinary” values. Operations should specify what happens when any of their operands are an error value. Operation should “throw” an error by producing an error value.

For JSON Logic, an error can arguably only be represented as JSON, so e.g. { "error": "<message>" }. (This would be an operation at the same time!) The drawback of that is that there might be clashes with existing data formats. Alternatively, you could specify that a JSON Logic implementation should have a runtime representation of errors. For a JS implementation, that would obviously mean an Errorr.

So, neither option embodies entirely what I meant.

[TotalTechGeek]

I believe that's what Option B is; "error" is just an operator that produces a JSON object, it's also the data format itself.

"try" allows you to coalesce the errors; but it must directly receive the error input.

The weakness of B is that this doesn't make operators monadic / strictly require handling of these issues, so the soft errors can propagate,

But it would be a native construct and far more efficient.

[gregsdennis]

I'm +1 on A (an error is an error until it's explicitly handled), -.5 on B.

However, if we're going to have this as a test (extracting the error)

{
    "description": "The context switches for the try coalescing to the previous error (2)",
    "rule": {
        "try": [
            { "if": [true, { "error": "Some error" }, null] },
            { "val": "error" }
        ]
    },
    "result": "Some error",
    "data": null
}

we should also have an example of catching a specific error. For example, how can I handle a NaN error but let others continue to bubble up?

[JTeeuwissen]

how can I handle a NaN error but let others continue to bubble up

One way would be to put an if statement in the catching expression, and to throw other errors again depending on the message.
Another operator, or other overloads are possible. But I'm not sure if there is a need.

[TotalTechGeek]

{
        "description": "Handles NaN Explicitly",
        "rule": {
            "try": [
                { "if": [{ "/": [1, { "val": "x" }] }, { "throw": "Some error" }, null] },
                {
                    "if": [{ "===": [{ "val": "type" }, "NaN"]}, "Handled", { "throw": { "val": [] } }]
                }
            ]
        },
        "result": "Handled",
        "data": { "x": 0 }
    },
    {
        "description": "Did not NaN, so it errored",
        "rule": {
            "try": [
                { "if": [{ "/": [1, { "val": "x" }] }, { "throw": "Some error" }, null] },
                { "if": [{ "===": [{ "val": "type" }, "NaN"]}, "Handled", { "throw": { "val": [] } }] }
            ]
        },
        "error": { "type": "Some error" },
        "data": { "x": 1 }
    }

This is a bit verbose, but without match / something similar it's not super pretty ;)

[TotalTechGeek]

Current Votes:

Name	Aggregate	TC Votes in Favor	Votes
A	5	3	@TotalTechGeek (+1) @gregsdennis (+1) @JTeeuwissen (+1) @codetiger (+1) @beeme1mr (+1)
B (Withdrawn)	N/A	VETOED	@gregsdennis (-.5) @TotalTechGeek (-1)

Needs one more approval for "A" to go through, @codetiger are you on board with A?

[TotalTechGeek]

@gregsdennis,

I apologize for doing this, I made some minor changes to Proposal A.

• error is renamed to throw
• The error object has type instead of error as a property.
  (These first two seem minor and cosmetic)
• error: Boolean is now error: JSONObject, which should at least partial match (equivalence allowed) against the error emitted. So instead of "error": true we can specify "error": { "type": "NaN" }.

I know that last bullet point you had some reservations on from JSON-E not clearly defining the error-cases / types.

However, if we're trying to make it so that you can handle specific error types, and that's already happening in try, I think it's already something we've stepped into with the val thing as you pointed out

It's defined as a partial match to leave room for us to define additional properties on it, w/o causing a bunch of test revisions.

[TotalTechGeek]

@toddbaert I realize OpenFeature likely does not require try / throw capabilities, but are y'all okay with this general direction? 😄

[codetiger]

+1 for Option A. It covers my requirements.

[TotalTechGeek]

I will move the Proposal into "Accepted" status

[beeme1mr]

Hey @TotalTechGeek, OpenFeature doesn't need try / throw but the proposal makes sense to me +1.