Custom Exceptions are confusing

[tejasbubane]

I was solving Circular Buffer today and had a hard time figuring out how to create custom exceptions. That is because I was expecting the matcher to match with a custom exception class, but what it actually does is matches with Error itself.

expect(()=>buffer.read()).toThrow(bufferEmptyException());

Note bufferEmptyException is a function call which gives no idea what its return type should be - Error/CustomError/String??

For custom exceptions in ES6, most sources say that this should suffice: (which is far better than its ES5 equivalent)

class bufferFullException extends Error {}

But it does not work since babel does not allow subclassing built-in classes (also mentioned in the docs). I ended up using the babel-plugin for allowing subclassing. Solution here.

Most other exercises just throw a String, while others like wordy and circular-buffer throw custom exceptions.
So I have two questions:

• Should we have a standard way of doing exceptions in the track? Is throwing Strings OK or should we go all custom?

• For the exercises that expect custom errors, is class bufferFullException extends Error {} better than what we have right now? which is:

const BufferFullException = () => ({
    name: "buffer full exception!",
    message: "can't write to a full buffer!"
  });

[matthewmorgan]

@tejasbubane I think there's value in revealing this feature of the language. Your work on #279 moved us from throwing a string to throwing an actual Error object, and I feel like this is another step in the right direction.

I am wondering if the plugin you mentioned could be part of our current Jest pipeline?

[tejasbubane]

I feel like this is another step in the right direction.

Glad you think the same. :)

I am wondering if the plugin you mentioned could be part of our current Jest pipeline?

Yes, we need to add the plugin as dependency and add this to babel settings in package.json:

    "plugins": [
      ["babel-plugin-transform-builtin-extend", {
        "globals": ["Error"]
      }]
    ]

I think it is safe since it allows only the Error builtin class to be extended and not others like Array, etc. And plays nice with Jest since we can now change this:

const BufferEmptyException = () => ({
  name: "buffer empty exception!",
  message: "can't read from an empty buffer!"
});

expect(()=>buffer.read()).toThrow(bufferEmptyException());

to this:

export class BufferEmptyException extends Error {};

expect(()=>buffer.read()).toThrow(BufferEmptyException);

Note: No function call, assertion on class. ☝️

I will open a PR and we can move the detailed discussion there.

[rchavarria]

Awesome! That would be really good! That's a language feature users will learn on exercism.io.

Should we have a standard way of doing exceptions in the track?

I think so. I don't mean to change all thrown Errors to custom exceptions, but at least, throw some kind of Error, not strings.

Canonical data for some exercises (I can't think of an example here) use -1 or other weird values to tell that an exception could be thrown. I think we could change those exercises to throw errors/exceptions instead of checking -1 or other flag values.