After my short Announcement yesterday, I’d like to go on an name some of the highlights.
Besides the basic functionality proposed in the original article, it has some more neat features, that make the life of its users enjoyable and fun.
So you better start using structured_warnings now.
Using the block syntax to disable warnings provides a dynamic scope of deactivation. Not only everything within the block will raise no warning, but every piece of code, that is accessed from there on. This can become very powerful for certain uses.
Last one wins
You never know exactly, so deactivating a warning for a dynamic scope may be overridden by enabling it again in a deeper scope and the other way round.
Each warning is passed to a warner instance, which it there to format the information, which is put to stdout. This warner may be changed for –again – a dynamic scope. This way you may instruct your favourite web framework to use a specific warner, that fetches all the information and writes it to a database instead of stdout.
Perhaps you want to have warnings in your merchant library to be to you via twitter message. Who knows? It will be pretty easy. Just have a look at the warner that is used for the test assertions. It will give you a good start.
Inheritance done right
Instead of redefining the
Kernel#warn method directly, structured_warnings
simply defines its own
warn. The module is mixed into Object, so that every
warn will go to this implementation first. After collecting all the necessary
information, checking if the current warning is not disabled and formatting the
output, the resulting message is passed on to the base implementation.
This way it is possible to add other extensions to you warning mechanism, you
may freely redirect stderr to whatever you want. structured_warnings
just do, what it is supposed to.
Fully documented sources
Today I finished the documentation part. Now each and every method, public or not is documented. Just have a look at the RDoc generated API site.
Come on. The main goal is to avoid the use of code, that raises warnings. With the help of this library it is as easy as it gets to do that. A warning should always be an exception (not in the sense of the Ruby class, but in the sense of “not common”), so who will be concerned about performance.
The only thing I can tell you is, that structured_warnings will slow down calls
warn but it will not slow down your whole code and that is what counts.
I mainly work with Rails, Backbone, and Bootstrap, but I am also good at picking up new frameworks, since I will probably know most of their concepts from other projects.