Spec refining: listing down the possible errors to be handled

[nicola]

Although we should do like many other similar specifications:

This specification does not define how errors are handled. An application SHOULD specify the impact and handling of each type of error (json pointers)

The spec should list out the different possible errors spec implementors and application developers will need to take into account. Let's keep this issue to list down all the possible erros. I am listing a few:

• CID has bad syntax (?)
• hash function not known (and all the others inherited from the multihash spec)
• Path referencing to non existent value

[dignifiedquire]

There should also be errors for

• invalid binary representation (for example if it gets corrupted)
• for CID
  • invalid or unknown multibase
  • invalid version
  • invalid or unknown multicodec

[jbenet]

• Some of these errors should be "grouped" under a general "invalid or malformed link". the more specific error can be given, but it will be useful (for everyone's sanity) to keep the error types down.
• if we do end up with different error types (beyond malformed stuff) we should consider defining int error codes, so implementations can agree.
• it is always a temptation (once you do that) to define a bunch of different errors (after all, you have all this int space, right?) but experience teaches that having super granular errors sometimes hurts more than having coarser errors. (ballooning complexity)

[nicola]

@jbenet I was event thinking of just:

This specification does not define how errors are handled. An application SHOULD specify the impact and handling of each type of error (json pointers)

If we want we can do a separate parser spec - not sure how much we want to standardize this (this is what JSON-pointers, JSON-ld & some others have done - we should look at cbor or xpath)

[rvagg]

Closing due to staleness as per team agreement to clean up the issue tracker a bit (ipld/team-mgmt#28). This doesn't mean this issue is off the table entirely, it's just not on the current active stack but may be revisited in the near future. If you feel there is something pertinent here, please speak up, reopen, or open a new issue. [/boilerplate]