Export errors from main

[rhys-vdw]

Export errors from module.

It's not possible to access code without using any. Export error classes for use in type guards.

import { FileNotFoundError } from "ts-simple-ast"

generate(paths)
  .then(() => {
    console.log('Done!')
  })
  .catch((error: Error) => {
    if (error.code === 'ENOENT') // [ts] Property 'code' does not exist on type 'Error'.
      console.error(error.message)

    if (error instanceof FileNotFoundError) // Good!
      console.error(error.message)
  })

[coveralls]

Coverage decreased (-0.01%) to 94.778% when pulling 35d3d65 on rhys-vdw:export-error into e82734b on dsherret:dev.

[dsherret]

I'm currently using these errors as internal helpers in a way and don't want to export all of them (exporting the folder also exports the actual errors/helpers.ts file, which should remain internal).

I'm thinking only the FileNotFoundError, DirectoryNotFoundError, and PathNotFoundError classes should be exported, but then I'm not sure about that at the moment... need to think it over more (leaning towards making FileNotFoundError and DirectoryNotFoundError inherit from PathNotFoundError and then only expose PathNotFoundError). What do you think?

[rhys-vdw]

Sounds fair, I'm actually not that familiar with all the other exceptions. The rule I would use is that any that can be thrown by the public API are part of the public API and should be exported. Any that are thrown and caught internally needn't be.

WRT inheritance hierarchies, I don't see much value in it. It seems like indirection. For example I got a FileNotFound error that I wanted to handle, so looked for the corresponding export to match it. It would not be obvious that I should have imported an error with a different name.

What's the point of subclassing if you do not export the errors?

[dsherret]

Good points! I exported all of them and will make a release soon (probably tomorrow).