Implement throws and mimicks behaviour fix - #80

I don't have any lint preferences, just don't make it too strict in my opinion.

Wow, this is awesome! Only thing missing is documentation and an example in the readme file! Code in libraries is only as good as its documentation.

Will merge right away when there's documentation! 👍👍👍

Actually, at second thought... We should mimick how NSubstitute throws exceptions, since this is a port of that library:

https://nsubstitute.github.io/help/throwing-exceptions/

Do you think that is possible in TypeScript?

Ironically I think your approach is actually better, but consistency is also quite important.

Documentation for throwing exceptions should still be there though.

I don't have any lint preferences, just don't make it too strict in my opinion.

Hahaha, I’ll ask only this -> Semicolon yes or no?

—-
I will take a look on the NSubstitute reference, and see what we can do. Currently I’m using mimicks to throw errors, but it feels quite hacky. If I recall correctly with .returns it was not possible as it takes always the arguments of the mocked property. But maybe it’s possible to have an override for returns, where it takes one argument of type Function => never

Semicolon definitely yes 😂

Alright. Mimicks is a substitute.js feature only anyway, so maybe it isn't that bad.

Feel free to give it a shot. If we can't do it, we'll merge this anyway.

But documentation is needed in either case 👍🙇

Hahaha that's what I imagined!

So, from what I saw, in NSubstitute when using .returns, you can also return a callback. With that, the possibility to throw an exception is achieved. But that's not possible with the current implementation of SusbtituteJS. It seems to me that .mimicks was created for that purpose?
I modified .returnsso if a return value is a callback, it gets called, but that would be a breaking change -> current implementations of .returnsreturning a function would be called before being returned.

So the options we have is:

1. We go with this pr's implementation - clear usecase distinction
2. We don't change anything and use .mimicks
3. We modify .returns to accept callbacks - breaking change

On any of the scenarios documentation will be added. I haven't written any, as we didn't decide where to go yet.
I prefer implementation 1, but maybe you prefer the 2nd or 3rd!

Alright, let's go with the original PR then. That's also very easy to understand.

Cool, I will add the documentation for the throws function!

There is the documentation, feel free to modify it or let me know if I should add something more!

Thanks!