Cannot handle thrown if not derived from Error

import { expect } from "chai";

class Exception {}

describe("chai", () => {
	it("should handle thrown object", () => {
        expect(()=> {
            throw new Exception();
        }).to.throw(Exception);
    });
});

1. chai should handle thrown object: AssertionError: expected [Function] to throw ‘Exception’ but {} was thrown

currently have to wrap as follows:

import { expect } from "chai";

class SentinelNoError {}
const sentinelNoError = new SentinelNoError();

function returnCatch(fn: ()=>void): any {
    try {
        fn();
        return sentinelNoError;
    } catch(error) {
        return error;
    }
}

class Exception {}

describe("chai", () => {
	it("should handle thrown object", () => {
        expect(returnCatch(()=> {
            throw new Exception();
        })).to.be.instanceof(Exception);
    });
});

[meeber]

@jseter The ability to provide arguments inside of the .throw assertion is just meant as a shortcut for the most common use cases, allowing a user to perform multiple assertions internally on the thrown value with a single assertion. It’s not meant to cover every possibility. The more possibilities it covers, the more complex (for Chai) and troublesome (for users) the code becomes, as described here.

Although this branch hasn’t been merged into Chai yet, the approach documented here should work for you in the current version of Chai.

import { expect } from "chai";

class Exception {}

describe("chai", () => {
  it("should handle thrown object", () => {
        expect(()=> {
            throw new Exception();
        }).to.throw().an.instanceof(Exception);
    });
});

[meeber]

@liuxh0 The good news is that using the .throw() assertion without any parameters causes it to only care about whether or not the function threw. It doesn’t care if an Error object was thrown, or some other object, or a string, or even undefined. And you can chain any of Chai’s other assertions (e.g., instanceof) afterward to make assertions on the thrown value.

The behavior of .throw when one or more parameters are passed isn’t quite right, I think. It’s likely that the solution I worked on last year isn’t perfect either. It’s a fair point that .throw shouldn’t care what type of value is thrown, even when passing parameters to .throw; otherwise, as you said, it’d be more like .throwError in that case.