Standardize error codes

[mikeal]

It's fairly standard practice to assign error codes of some sort to the exceptions in order to be less dependent on parsing the text of the error messages. Example:

const getJSON = async (ipfs, path) => {
  let buff = null
  try {
    buff = await ipfs.files.read(path)
  } catch (e) {
    if (e.message !== 'file does not exist') throw e
  }
  if (!buff) return buff
  return JSON.parse(buff.toString())
}

This means that the error message is effectively part of the API and changing it will break compatibility, which we probably don't want.

Also, since we have a standard API across implementations in the same language (js-ipfs, js-ipfs-api) we can write new modules that allow the API implementation to be passed in. But, if part of that API does some error checking we would need the messages to be 100% consistent or have a standardized error code across them.

const getJSON = async (ipfs, path) => {
  let buff = null
  try {
    buff = await ipfs.files.read(path)
  } catch (e) {
    if (e.code !== 404) throw e
  }
  if (!buff) return buff
  return JSON.parse(buff.toString())
}

[achingbrain]

Yes please. Some motion has been made toward this but really we need to implement the same thing in go-ipfs' http api.

[whizzzkid]

js-ipfs is being deprecated in favor of Helia. You can #4336 and read the migration guide.

Please feel to reopen with any comments before 2023-06-05. We will do a final pass on reopened issues afterward (see #4336).

This might already be resolved in Helia, if not please feel free to create an issue there.