Parable about interception of errors

- Hello, my friend. Do you want me to tell you a fairy tale? }: -]
- Of course, uncle, and what? * _ *
- I will tell you how to make children ^ _ ^ '
- wow, how interesting! @ _ @
- So, listen. Children appear as a result of a long and exhausting process of varying degrees of obscenity. Now I will tell you how my son was born% -)
- Did you introduce me to him? *about*
- Do not rush things. Everything in order. Once I made this code:

1. try { throw new Error } catch ( e ){ if ( e != false ) throw e }
2. try { throw new Error } catch ( e ){ if ( e != false ) throw e }
3. try { throw new Error } catch ( e ){ if ( e != false ) throw e }
4. try { throw new Error } catch ( e ){ if ( e != false ) throw e }
5. try { throw new Error } catch ( e ){ if ( e != false ) throw e }

- What does he do? o_0
- It doesn’t matter, the main thing is different here, namely that only Opera and Mozilla in the error console pointed to the second line of the script. Chrome pointed to the fourth, and Ishak in general to the third .-.
- Well, so what? ._.
- And the fact that the use of such constructions of sending additional exceptions generally leads to the fact that exceptions lose their coordinates and become completely useless when debugging. We know that an error has occurred, we even know what it is, but we can only establish by a scientific method where it happened. In addition, some debuggers have a useful function of switching to the step-by-step debugging mode in case of an error ... Guess where the stop of execution will occur
- Then you should not do it and everything will be fine! \ (^ _ ^) /
- Heh, if everything was so simple ... Unfortunately, in all popular frameworks there are similar freaks, and in many cases the errors are simply swallowed: - \
- So do not use them and all things! =)
- Phah! Naive little boy! This is impossible ... for various reasons ... = (
- Why? And what else is left? o0 '
- Well, I just patched the framework used by us, clearing all interceptions of errors of our application, though it slightly violated it api = _ =
- Wow, what are you doing there like that? 0_0
- Well, catch an example:

1. each: function (iterator, context) {
2. var index = 0;
3. try {
4. this ._each ( function (value) {
5. iterator.call (context, value, index ++);
6. });
7. } catch (e) {
8. if (e! = $ break ) throw e;
9. }
10. return this ;
11. },

- What is it? + _ + '
- This is an iteration function from prototypeJS. It can be seen that its developers were not at all engaged in debugging scripts in browsers of excellent firewall, since they implemented the interruption of the filter in this way. I won’t bother you with a javascript - I’ll just say that I cut out try-catch, and in all iterators I registered an additional parameter transmission, the return of which interrupts the iteration ^ _ ^
- How it all ended well! :-)
- No, it has just begun ... It is not always possible to simply take and cut the iteration, because sometimes you need to execute some kind of unsafe code so that it does not interrupt our execution. Here, catch an example from jQuery:

1. // Trigger an inline bound script
2. try {
3. if (! (elem && elem.nodeName && jQuery.noData [elem.nodeName.toLowerCase ()])) {
4. if (elem [ "on" + type] && elem [ "on" + type] .apply (elem, data) === false ) {
5. event .result = false ;
6. }
7. }
8. // prevent IE from some event types, see # 3533
9. } catch (e) {}

- Oh, and how to be then? o_o '
- Well, here I stole a little Dean Edwards seed ( dean.edwards.name/weblog/2009/03/callbacks-vs-events ) and spawned a wrapper that executes some piece of code safely from the rest, without in any way catching the exception , and giving them to the care of the debugger B-]
- What? :-ABOUT
- Roughly speaking, the last code can be rewritten as follows, calling for the help of my son named FThread:

1. // Trigger an inline bound script
2. // prevent IE from some event types, see # 3533
3. FThread ( function () {
4. if (! (elem && elem.nodeName && jQuery.noData [elem.nodeName.toLowerCase ()])) {
5. if (elem [ "on" + type] && elem [ "on" + type] .apply (elem, data) === false ) {
6. event .result = false ;
7. }
8. }
9. }). call ( this )

- And if not so rude? : - [
- M ... my friend, better I will leave you alone - he will eloquently tell everything about himself ;-)

var FThread= new function (){<br><br> Version: 4<br> Description: 'creates a wrapper for function that allows you to not be afraid of exceptions in' <br> License: 'public domain' <br> <br> Implementation: <br><br> var scripts= document .getElementsByTagName( 'script' )<br> var script= scripts[ scripts.length - 1 ]<br> var starter= document .createElement( 'button' )<br>starter.id= 'thread starter' <br>starter.style.display= 'none' <br>script.parentNode.insertBefore( starter, script )<br><br> var FThread= function ( proc ){<br> var thread= function ( ){<br> var res, self= this , args= arguments<br> starter.onclick= function ( ev ){<br> ( ev || event ).cancelBubble= true <br> starter.onclick= null <br> res= thread.proc.apply( self, args )<br> }<br> starter.click()<br> return res<br> }<br> thread.proc= proc<br> return thread<br>}<br><br><br> Export: return FThread<br><br> Usage: <br><br> var inverse= FThread( function ( a ){<br> if ( a === -1 ) ( void 0)()<br> if ( a === 0 ) throw Error( 'division by zero' )<br> return 1/a<br>})<br>alert([ inverse( -1 ), inverse( 0 ), inverse( 1 ) ])<br> // alerts ",,1" and two exceptions in console log <br><br>}