Usage of exceptions/errors?

[k00ni]

The specification currently doesn't specific certain errors or exceptions. Is that intended? Would you open to define ones for certain cases?

One would be if someone tries to change an instance of Term or Quad. But perhaps the decision was already made against that (ref #81).

Another one, if you use the wrong Term subclass in a quad, e.g. predicate = BlankNode.

(ref #130)

[bergos]

Both cases are not handled by the spec. Also in JS it's not very common to make custom error classes. And instanceof should not be used, as this could cause problems with different implementations.

[blake-regalia]

I think this is important for all methods. For instance, if null is passed to NamedNode.equals(), should this throw an Error or return false? Right now, the org data model test suite requires these methods return false but this is not defined in the interface specification -- I recommended we either remove this from the test suite or define it in the interface spec.

[k00ni]

I'd rather prefer clear exceptions or just errors, but with defined error texts, instead of returning false. In a complex environment, a returned false says nothing about the state of the previous operation. Giving the user a way to gather critical information is important, if you handle invalid data, while parsing for instance.

[k00ni]

As a starting point, i propose the following exceptions:

InvalidTermUsageInQuadException

• Throw if: you use an invalid instance of Term in Quad.
• Example: use a Literal instance as subject
• Texts:
  • invalid subject: Subject can only be one of: BlankNode, NamedNode, Variable
  • invalid predicate: Predicate can only be one of: NamedNode, Variable
  • invalid object: Object can only be one of: BlankNode, Literal, NamedNode, Variable
  • invalid graph: Graph can only be one of: BlankNode, DefaultGraph, NamedNode, Variable

ObjectNotMutableException

• Throw if: you try to change an instance of Term or Quad.

UndefinedPropertyException

• Throw if: you try to access an undefined property of an instance of Term or Quad. Predefined are subject, predicate, object and graph in Quad and value, termType in Term.

[RubenVerborgh]

2 is not idiomatic; 3 not enforceable on regular objects (except for proxies)

[blake-regalia]

I think the best we can hope for would be to say that certain methods should throw an Error, maybe even for example a TypeError, if provided an argument that is not a Term, Quad, etc. This is critical for debugging if a variable in a dev's code is not properly initialized and passes undefined to say, .equals(term). Returning false instead of throwing is not a convenience, it only further obscures the source of such problems.

[RubenVerborgh]

I disagree. A false for me is expected behavior; I asked whether the thing is equal and the answer is clearly no.

Debugging is not hard: the equals method will return false, so that's not harder to debug than an actual Term that would also be unequal.

[blake-regalia]

A false for me is expected behavior

Not for me... I'd expect equality to be symmetric

let term = factory.namedNode('a');
let undef;
term.equals(undef);  // false
undef.equals(term);  // > TypeError: Cannot read property 'equals' of undefined

[RubenVerborgh]

Good point about symmetry, but I assume you don't want TypeError: Cannot read property 'equals' of undefined for term.equals(undef), so how much is symmetry worth 😉

[blake-regalia]

The symmetry is that they both would throw an error, whether or not the return value from the .toString() method of one error is identical to the other is not important. What's important about symmetry is that switching which side of the operator a variable is on does not cause different effects on the rest of a program, namely branching as a result of false if term is on the left rather than on the right.

[bergos]

I'm against throwing an error. Maybe in TypeScript, but it's not very "JSish". In JS I don't expect any type error. "not null" or "no empty string" etc. is OK, but type checks are so blurry in JS. Think of this case:

const term = factory.namedNode('a')
const other = {}

term.equals(other) // false, cause term.termType !== other.termType

[blake-regalia]

The bigger point is that we are doing nobody any favors by returning false for a falsy other argument. I guarantee that nobody is intentionally testing if term.equals(null) or term.equals(false) or term.equals(undefined) or term.equals(0) or term.equals('') or term.equals(). If the developer is even aware of the possibility that the value of their argument to .equals for example might be falsy, they will do a falsy check on their own anyway before calling .equals. Nobody is going to think "ahh - how convenient, I can just pass this possibly undefined value to .equals without checking for falsyness first"

[RubenVerborgh]

The bigger point is that we are doing nobody any favors by returning false for a falsy other argument.

Me; I don't have to write a catch handler ever.

Nobody is going to think "ahh - how convenient, I can just pass this possibly undefined value to .equals without checking for falsyness first"

That would be me.

I've just always written equals methods to return booleans and not throw; I think this stems from the Java definition of it, which does not throw under any circumstance.

We do not have a lot to go in in JavaScript-land though, except for Object.is.

My notion of equals seems to be the same as that of Object.is, but I don't have much evidence regarding whether or not throwing for falsy values (BTW why not for truthy?) is idiomatic. I see exceptions for ways where methods cannot give a proper answer, I think for equals there always is (depending on your exact definition of it, of course).

[elf-pavlik]

I don't have to write a catch handler ever.

To assume that equals() will not throw, does spec need to mandate MUST NOT to throw? Besides saying nothing, we have at least option to say MUST NOT, MAY, SHOULD, MUST. Depending on that implementations could make different assumptions about behavior (including not to assume anything about throwing from equals())