browserify / commonjs-assert

Node.js's require('assert') for all engines
MIT License
293 stars 57 forks source link

Ability to customize errors #14

Closed kharandziuk closed 8 years ago

kharandziuk commented 8 years ago

I have two usecases:

  1. I need to show Alert window on an every assertion error
  2. I need to send log message on an every assertion error

Now I resolve it via forking the library and and adding some code to the AssertionError constructor. Is it Make sense to provide a generic way to do this?

defunctzombie commented 8 years ago

Unlikely that there will be a generic way to do this. The main purpose of this library is to provide basic assertion testing routines that just throw when they assert.

Options include making a module which wraps this one with whatever hooks you need or maybe the browser has a watch to catch all errors and you can inspect them for AssertionError.

In general assertion error usecase is targeted for tests or to assert when the code cannot continue if the assertion fails.

kharandziuk commented 8 years ago

browser has a watch to catch all errors and you can inspect them for AssertionError

As you know it a bad practice to catch and handle assertion errors. And there is no way to watch on the console events http://stackoverflow.com/questions/33369273/subscribe-on-console-events-in-a-browser

in general assertion error usecase is targeted for tests or to assert when the code cannot continue if the assertion fails.

yep, you are right. But not all the users knows about the console where they can see the message. So instead of something meaningful like "there is an assertion: "response has no code property", we have a bug reports like "everything stoped to work"

defunctzombie commented 8 years ago

I don't disagree that there may be better approaches or libraries you can build. The focus of this module is largely to be a modular version of simple commonjs assertion code found in nodejs. I would most recommend that you either propose a PR with a use case or best yet is usually to build a module to do the specific thing you want to do leveraging this module if needed.

kharandziuk commented 8 years ago

Actually we are talking about a feature. I provided some usecases. On the moment it's unclear for me: should I provide a PR?

best yet is usually to build a module to do the specific thing you want to do leveraging this module if needed.

As I said: Now I resolve it via forking the library and and adding some code to the AssertionError constructor.

But it's a little bit ugly

defunctzombie commented 8 years ago

Unless it is really simple and compelling I am unlikely to merge as this module is pretty much frozen as is due to the intended purpose of the module.