Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #12916 > unrolled thread

Pokémon Error Handling: Gotta Catch 'Em All

Back to article view | Back to comp.lang.javascript

Contents

  Pokémon Error Handling: Gotta Catch 'Em All Gene Wirchenko <genew@ocis.net> - 2012-03-19 18:37 -0700
    Re: Pokémon Error Handling: Gotta Catch 'Em All David Mark <dmark.cinsoft@gmail.com> - 2012-03-19 18:52 -0700
      Re: Pokémon Error Handling: Gotta Catch 'Em All Gene Wirchenko <genew@ocis.net> - 2012-03-19 22:26 -0700
        Re: Pokémon Error Handling: Gotta Catch 'Em All David Mark <dmark.cinsoft@gmail.com> - 2012-03-19 23:08 -0700
    Re: Pokémon Error Handling: Gotta Catch 'Em All Jeff North <jnorthau@yahoo.com.au> - 2012-03-20 18:20 +1100
      Re: Pokémon Error Handling: Gotta Catch 'Em All Gene Wirchenko <genew@ocis.net> - 2012-03-20 08:13 -0700
        Re: Pokémon Error Handling: Gotta Catch 'Em All David Mark <dmark.cinsoft@gmail.com> - 2012-03-20 16:31 -0700
          Re: Pokémon Error Handling: Gotta Catch 'Em All Gene Wirchenko <genew@ocis.net> - 2012-03-20 19:33 -0700
            Re: Pokémon Error Handling: Gotta Catch 'Em All David Mark <dmark.cinsoft@gmail.com> - 2012-03-28 21:48 -0700
              Re: Pokémon Error Handling: Gotta Catch 'Em All Gene Wirchenko <genew@ocis.net> - 2012-04-02 21:05 -0700
    Re: Pokémon Error Handling: Gotta Catch 'Em All flensingknife@gmail.com - 2012-03-31 18:45 -0700
      Re: Pokémon Error Handling: Gotta Catch 'Em All Gene Wirchenko <genew@ocis.net> - 2012-04-02 14:49 -0700
    Re: Pokémon Error Handling: Gotta Catch 'Em All flensingknife@gmail.com - 2012-03-31 18:49 -0700
      Re: Pokémon Error Handling: Gotta Catch 'Em All David Mark <dmark.cinsoft@gmail.com> - 2012-04-01 11:18 -0700

#12916 — Pokémon Error Handling: Gotta Catch 'Em All

Dear JavaScripters:

     A while back, I wrote a date object which has try...catch in it.
I would like to catch those errors in my form.  Conceptually, I would
like something like:
          try
            {
            <form>
              lots of stuff here
            </form>
            }
           catch
             {
             general error handler
             }

     How would I do this if my form was defined in static HTML?

     How do I do this if most of the form is actually generated by
JavaScript code?  This is what I really want.

     I suppose I could have very ugly code like
          <input ...
      onfocus="try { DoFocus(this); } catch(e) { ErrHandler(e); }"
      onblur="try { DoBlur(this); } catch(e) { ErrHandler(e); }"
          >
repeated ad nauseum, but I am hoping for something nicer.

     What should I be reading up on now, please?

Sincerely,

Gene Wirchenko

[toc] | [next] | [standalone]

#12919

On Mar 19, 9:37 pm, Gene Wirchenko <ge...@ocis.net> wrote:
> Dear JavaScripters:
>
>      A while back, I wrote a date object which has try...catch in it.
> I would like to catch those errors in my form.  Conceptually, I would
> like something like:
>           try
>             {
>             <form>
>               lots of stuff here
>             </form>
>             }
>            catch
>              {
>              general error handler
>              }

Huh?

>
>      How would I do this if my form was defined in static HTML?
>
>      How do I do this if most of the form is actually generated by
> JavaScript code?  This is what I really want.
>
>      I suppose I could have very ugly code like
>           <input ...
>       onfocus="try { DoFocus(this); } catch(e) { ErrHandler(e); }"
>       onblur="try { DoBlur(this); } catch(e) { ErrHandler(e); }"
>           >
> repeated ad nauseum, but I am hoping for something nicer.
>
>      What should I be reading up on now, please?
>

Exception handling in browser scripting is typically relegated to host
object feature detection/testing.  The last thing you want to do is
hide mistakes in your logic from yourself.  If something fails, it is
not typically productive to squash the exception and carry on like
nothing happened.  On the contrary, the exception (and accompanying
stack trace) holds the clue that helps you to find your mistake.

What is it that you think will fail in your DoFocus/Blur functions?

[toc] | [prev] | [next] | [standalone]

#12920

On Mon, 19 Mar 2012 18:52:59 -0700 (PDT), David Mark
<dmark.cinsoft@gmail.com> wrote:

>On Mar 19, 9:37 pm, Gene Wirchenko <ge...@ocis.net> wrote:
>> Dear JavaScripters:
>>
>>      A while back, I wrote a date object which has try...catch in it.
>> I would like to catch those errors in my form.  Conceptually, I would
>> like something like:
>>           try
>>             {
>>             <form>
>>               lots of stuff here
>>             </form>
>>             }
>>            catch
>>              {
>>              general error handler
>>              }
>
>Huh?

     Did you miss the word "[C]onceptually"?

>>      How would I do this if my form was defined in static HTML?
>>
>>      How do I do this if most of the form is actually generated by
>> JavaScript code?  This is what I really want.
>>
>>      I suppose I could have very ugly code like
>>           <input ...
>>       onfocus="try { DoFocus(this); } catch(e) { ErrHandler(e); }"
>>       onblur="try { DoBlur(this); } catch(e) { ErrHandler(e); }"
>>           >
>> repeated ad nauseum, but I am hoping for something nicer.
>>
>>      What should I be reading up on now, please?

>Exception handling in browser scripting is typically relegated to host
>object feature detection/testing.  The last thing you want to do is
>hide mistakes in your logic from yourself.  If something fails, it is
>not typically productive to squash the exception and carry on like
>nothing happened.  On the contrary, the exception (and accompanying
>stack trace) holds the clue that helps you to find your mistake.
>
>What is it that you think will fail in your DoFocus/Blur functions?

     I do not know, but whatever it might be, I want to know about it.
How do I catch all of these short of putting a lot of try...catch code
in my on*= clauses?

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12923

On Mar 20, 1:26 am, Gene Wirchenko <ge...@ocis.net> wrote:
> On Mon, 19 Mar 2012 18:52:59 -0700 (PDT), David Mark
>
>
>
>
>
>
>
>
>
> <dmark.cins...@gmail.com> wrote:
> >On Mar 19, 9:37 pm, Gene Wirchenko <ge...@ocis.net> wrote:
> >> Dear JavaScripters:
>
> >>      A while back, I wrote a date object which has try...catch in it.
> >> I would like to catch those errors in my form.  Conceptually, I would
> >> like something like:
> >>           try
> >>             {
> >>             <form>
> >>               lots of stuff here
> >>             </form>
> >>             }
> >>            catch
> >>              {
> >>              general error handler
> >>              }
>
> >Huh?
>
>      Did you miss the word "[C]onceptually"?

No.  The illustration of your concept just doesn't make sense to me.

>
>
>
>
>
>
>
>
>
> >>      How would I do this if my form was defined in static HTML?
>
> >>      How do I do this if most of the form is actually generated by
> >> JavaScript code?  This is what I really want.
>
> >>      I suppose I could have very ugly code like
> >>           <input ...
> >>       onfocus="try { DoFocus(this); } catch(e) { ErrHandler(e); }"
> >>       onblur="try { DoBlur(this); } catch(e) { ErrHandler(e); }"
> >>           >
> >> repeated ad nauseum, but I am hoping for something nicer.
>
> >>      What should I be reading up on now, please?
> >Exception handling in browser scripting is typically relegated to host
> >object feature detection/testing.  The last thing you want to do is
> >hide mistakes in your logic from yourself.  If something fails, it is
> >not typically productive to squash the exception and carry on like
> >nothing happened.  On the contrary, the exception (and accompanying
> >stack trace) holds the clue that helps you to find your mistake.
>
> >What is it that you think will fail in your DoFocus/Blur functions?
>
>      I do not know, but whatever it might be, I want to know about it.
> How do I catch all of these short of putting a lot of try...catch code
> in my on*= clauses?

You want to avoid try-catch whenever possible (and it's virtually
always possible, except when dealing with host objects).  If you want
to know about exceptions, check the console.

[toc] | [prev] | [next] | [standalone]

#12926

On Mon, 19 Mar 2012 18:37:53 -0700, in comp.lang.javascript Gene
Wirchenko <genew@ocis.net>
<vbnfm7dg9ekk8691dhslu26rffflb76nps@4ax.com> wrote:

>| Dear JavaScripters:
>| 
>|      A while back, I wrote a date object which has try...catch in it.
>| I would like to catch those errors in my form.  Conceptually, I would
>| like something like:
>|           try
>|             {
>|             <form>
>|               lots of stuff here
>|             </form>
>|             }
>|            catch
>|              {
>|              general error handler
>|              }
>| 
>|      How would I do this if my form was defined in static HTML?
>| 
>|      How do I do this if most of the form is actually generated by
>| JavaScript code?  This is what I really want.
>| 
>|      I suppose I could have very ugly code like
>|           <input ...
>|       onfocus="try { DoFocus(this); } catch(e) { ErrHandler(e); }"
>|       onblur="try { DoBlur(this); } catch(e) { ErrHandler(e); }"
>|           >
>| repeated ad nauseum, but I am hoping for something nicer.
>| 
>|      What should I be reading up on now, please?

So you are trying to catch an error if you haven't written the
function and passing it off to the error handler.

You could simply look at the console.log output.

If you want to automate this onfocus/onblur events then write some js
to attach the event to each control within your form.

[toc] | [prev] | [next] | [standalone]

#12930

On Tue, 20 Mar 2012 18:20:46 +1100, Jeff North <jnorthau@yahoo.com.au>
wrote:

>On Mon, 19 Mar 2012 18:37:53 -0700, in comp.lang.javascript Gene
>Wirchenko <genew@ocis.net>
><vbnfm7dg9ekk8691dhslu26rffflb76nps@4ax.com> wrote:
>
>>| Dear JavaScripters:
>>| 
>>|      A while back, I wrote a date object which has try...catch in it.
>>| I would like to catch those errors in my form.  Conceptually, I would
>>| like something like:
>>|           try
>>|             {
>>|             <form>
>>|               lots of stuff here
>>|             </form>
>>|             }
>>|            catch
>>|              {
>>|              general error handler
>>|              }
>>| 
>>|      How would I do this if my form was defined in static HTML?
>>| 
>>|      How do I do this if most of the form is actually generated by
>>| JavaScript code?  This is what I really want.
>>| 
>>|      I suppose I could have very ugly code like
>>|           <input ...
>>|       onfocus="try { DoFocus(this); } catch(e) { ErrHandler(e); }"
>>|       onblur="try { DoBlur(this); } catch(e) { ErrHandler(e); }"
>>|           >
>>| repeated ad nauseum, but I am hoping for something nicer.
>>| 
>>|      What should I be reading up on now, please?
>
>So you are trying to catch an error if you haven't written the
>function and passing it off to the error handler.

     What does this sentence fragment mean?

>You could simply look at the console.log output.

     The intent was for an error to be reported so that the user is
aware that an error occurred.

>If you want to automate this onfocus/onblur events then write some js
>to attach the event to each control within your form.

     I already do that in that I generate the HTML for the control in
JavaScript.  I want to avoid gratuitous complication.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12937

On Mar 20, 11:13 am, Gene Wirchenko <ge...@ocis.net> wrote:
> On Tue, 20 Mar 2012 18:20:46 +1100, Jeff North <jnort...@yahoo.com.au>
> wrote:
>
>
>
>
>
>
>
>
>
> >On Mon, 19 Mar 2012 18:37:53 -0700, in comp.lang.javascript Gene
> >Wirchenko <ge...@ocis.net>
> ><vbnfm7dg9ekk8691dhslu26rffflb76...@4ax.com> wrote:
>
> >>| Dear JavaScripters:
> >>|
> >>|      A while back, I wrote a date object which has try...catch in it.
> >>| I would like to catch those errors in my form.  Conceptually, I would
> >>| like something like:
> >>|           try
> >>|             {
> >>|             <form>
> >>|               lots of stuff here
> >>|             </form>
> >>|             }
> >>|            catch
> >>|              {
> >>|              general error handler
> >>|              }
> >>|
> >>|      How would I do this if my form was defined in static HTML?
> >>|
> >>|      How do I do this if most of the form is actually generated by
> >>| JavaScript code?  This is what I really want.
> >>|
> >>|      I suppose I could have very ugly code like
> >>|           <input ...
> >>|       onfocus="try { DoFocus(this); } catch(e) { ErrHandler(e); }"
> >>|       onblur="try { DoBlur(this); } catch(e) { ErrHandler(e); }"
> >>|           >
> >>| repeated ad nauseum, but I am hoping for something nicer.
> >>|
> >>|      What should I be reading up on now, please?
>
> >So you are trying to catch an error if you haven't written the
> >function and passing it off to the error handler.
>
>      What does this sentence fragment mean?
>
> >You could simply look at the console.log output.
>
>      The intent was for an error to be reported so that the user is
> aware that an error occurred.

Exceptions are for developers, not users.  Presumably the gaps in
logic that cause exceptions are filled before the application is in
the hands of users. ;)

[toc] | [prev] | [next] | [standalone]

#12944

On Tue, 20 Mar 2012 16:31:33 -0700 (PDT), David Mark
<dmark.cinsoft@gmail.com> wrote:

[snip]

>Exceptions are for developers, not users.  Presumably the gaps in
>logic that cause exceptions are filled before the application is in
>the hands of users. ;)

     One can hope for it, but how will I know if I can not catch them?

     I do not expect to be able to handle them then, but if I get
told, "Hey, Gene.  CBS3 just coughed up:
          Error in cwkfform
          JustDate: Bad constructor call signature.
          Current control is trndtlow.",
I have a chance of nailing it.  Without that, I have little chance if
it is an insidious bug.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#13151

On Mar 20, 10:33 pm, Gene Wirchenko <ge...@ocis.net> wrote:
> On Tue, 20 Mar 2012 16:31:33 -0700 (PDT), David Mark
>
> <dmark.cins...@gmail.com> wrote:
>
> [snip]
>
> >Exceptions are for developers, not users.  Presumably the gaps in
> >logic that cause exceptions are filled before the application is in
> >the hands of users. ;)
>
>      One can hope for it, but how will I know if I can not catch them?

Check the console. ;)

>
>      I do not expect to be able to handle them then, but if I get
> told, "Hey, Gene.  CBS3 just coughed up:
>           Error in cwkfform
>           JustDate: Bad constructor call signature.
>           Current control is trndtlow.",
> I have a chance of nailing it.  Without that, I have little chance if
> it is an insidious bug.

No, you've got the wrong end of the stick there.  What you want there
is a preemptive *throw* in the constructor (which should be removed on
release).  And bugs are bugs, none any more "insidious" than the next.

Catching exceptions and then throwing new ones destroys valuable
evidence (see Dojo).  And if you must rely on others to relate
exceptions, stack traces, etc. you better train them on evidence
gathering.  Furthermore, you shouldn't release code to QA (or
whomever) until you have tested it thoroughly (i.e. it doesn't throw
exceptions at that point).

[toc] | [prev] | [next] | [standalone]

#13184

On Wed, 28 Mar 2012 21:48:29 -0700 (PDT), David Mark
<dmark.cinsoft@gmail.com> wrote:

>On Mar 20, 10:33 pm, Gene Wirchenko <ge...@ocis.net> wrote:

[snip]

>>      I do not expect to be able to handle them then, but if I get
>> told, "Hey, Gene.  CBS3 just coughed up:
>>           Error in cwkfform
>>           JustDate: Bad constructor call signature.
>>           Current control is trndtlow.",
>> I have a chance of nailing it.  Without that, I have little chance if
>> it is an insidious bug.
>
>No, you've got the wrong end of the stick there.  What you want there
>is a preemptive *throw* in the constructor (which should be removed on
>release).  And bugs are bugs, none any more "insidious" than the next.

     Of course there are insidious bugs.  Some are easy to find once
one knows about them.  Others require more work, sometimes much more.

>Catching exceptions and then throwing new ones destroys valuable
>evidence (see Dojo).  And if you must rely on others to relate
>exceptions, stack traces, etc. you better train them on evidence
>gathering.  Furthermore, you shouldn't release code to QA (or
>whomever) until you have tested it thoroughly (i.e. it doesn't throw
>exceptions at that point).

     I do plan to test thoroughly.  Nonetheless, a bug may show up in
production anyway.  It might not be my fault.  It will not matter.  I
will still have to deal with it.

.    I would like to get the data so that I can nail it.  The point of
my request is so that I have some simple instructions for the users.
"If you see an error that looks like <whatever>, please write down the
text and let me know."

     So what should I do to get this data?

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#13172

>>So you are trying to catch an error if you haven't written the
>>function and passing it off to the error handler.

>What does this sentence fragment mean?

This is not a sentence fragment, it's a fully formed proper English sentence with a subject, verb, and predicate.

Just sayin...

[toc] | [prev] | [next] | [standalone]

#13178

On Sat, 31 Mar 2012 18:45:53 -0700 (PDT), flensingknife@gmail.com
wrote:

>>>So you are trying to catch an error if you haven't written the
>>>function and passing it off to the error handler.
>
>>What does this sentence fragment mean?
>
>This is not a sentence fragment, it's a fully formed proper English sentence with a subject, verb, and predicate.
>
>Just sayin...

     It is quite possible for a sentence to have subject, verb, and
predicate and yet be a sentence fragment.  Your fragment is part of a
complex sentence.

     I still do not know what you mean by it.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#13173

> Check the console. ;) 
In other words, what Jeff North said earlier.

Wow, this shithole hasn't improved at all, it's still full of egotistical epeen bullshit. 

Maybe I'll come back in three years and see if the rotting corpse has skeletonized.

[toc] | [prev] | [next] | [standalone]

#13174

On Mar 31, 9:49 pm, flensingkn...@gmail.com wrote:
> > Check the console. ;)
>
> In other words, what Jeff North said earlier.

Then he was right too. :)

>
> Wow, this shithole hasn't improved at all, it's still full of egotistical epeen bullshit.

Have you considered that the problem is on your end?

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web