dcsimg


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 4 of 8 FirstFirst ... 23456 ... LastLast
Results 46 to 60 of 109

Thread: Correct Error Handling

  1. #46
    Ronald Dolman Guest

    Re: Correct Error Handling

    Kathleen,

    > We've done the "Kathleen passionately hates code generators" stuff haven't

    we?

    A bit off topic, but just curious, what is your opinion about UML tools like
    say Rational Rose?

    Ronald



  2. #47
    Richard Curzon Guest

    Re: Correct Error Handling


    Kathleen Dollard-Joeris <kjoeris@noemailplease.com> wrote in message
    news:3922bf1c@news.devx.com...
    >
    > We've done the "Kathleen passionately hates code generators" stuff haven't
    > we? And I really get annoyed when this cool Add-In tool gets used as a

    code
    > generator. I mean if nothing else, how many extra bytes do you add to the
    > EXE when there is a better way (I don't care about bytes when it is the

    best
    > way. Such a cop-out Richard to blame the add-in!


    If I wasn't clear, I love the add-in. If there was anything about what it
    did I didn't like, I'd change it.

    So those lines you put in over and over, to declare your mousepointer object
    and instantiate it, you enjoy doing that manually?. It's part of the art,
    it's typing excercise, it's like a mantra, helps you focus? <big grin>

    Ideally, language designers would go out to the world, and find the people
    who use the "best practices". Primarily in the business/corporate world
    where the tool is actually used to solve most problems, where the money
    comes from that makes MS what it is.

    And they'd say, these things that are done over and over again in best
    practice, that are done manually, where you can see people are trying to
    overcome some "feature" or lack of a "feature".... how can we build that in
    to the language so it happens more automatically, more declaratively, more
    behind the scenes?

    I'd love it if I didn't have to run George's VB Builder to assign temporary
    line numbers during a build just so I could get the line number the error
    happened on. Why isn't that a declarative option of a module or a project?
    If an sub had a declarative option for error handling, like "show error and
    line number with this caption locally" or "reraise any error to the caller,
    append the local error message to description" then I wouldn't have to write
    that code. And of course, I wouldn't automate it either.

    But where the VB tool falls short, you have to do a thing over and over
    again. You must be one ornery stubborn curmudgeon if you just don't want to
    automate it! We'll wait for you in the pub while you finish up all that
    typing .... <bg>

    > > Okay, a little challenge to all who use CallStack or similar things...
    > > nobody wants to tell me why,

    > It is easy and it is what people expect.


    Thank you, Exhibit B!

    regards
    Richard.



  3. #48
    Richard Curzon Guest

    Re: Correct Error Handling

    Mike Culley <m_culley@one.net.au> wrote in message
    news:39209847$1@news.devx.com...

    Well, thank you, Exhibit A. I confess no matter how often I hear them , I'm
    slightly amazed when I read statements like

    > this make the app generally quicker - even if there is no speed issue


    but thankyou, because I know you are speaking for the majority!

    Very little of what goes on in a typical programmers head has any
    tracability to the requirements, nor does it show any thorough knowledge of
    the tool.

    We would be humiliated if our peers caught us using a variant, so we avoid
    variants. Even if there is a good reason, e.g. ability to hold a Null when
    dealing with a database, and there is no measurable speed cost.

    So it happens, we can actually say these things to each other "I do that
    for speed, even though it has no measurable effect on speed":

    It isn't only VB programmers who don't think, it's everywhere... <grumble
    grumble>

    regards
    Richard.

    > Richard,
    >
    > I understand what you are saying, but I would not use your method. It only
    > my way of coding, but I try to code as efficiently as possible from the

    start,
    > this make the app generally quicker - even if there is no speed issue it
    > is better to have it run faster.
    >
    > Generally, I can find the error with just a call stack, or just the error
    > and location. It may be harder to find, but that is a tradeoff.
    >
    > Michael Culley
    >
    > "Richard Curzon" <richardcurzon@home.com> wrote:
    > >
    > >Michael Culley <m_culley@one.net.au> wrote in message
    > >news:391ea4a5$1@news.devx.com...
    > >>
    > >> Richard
    > >>
    > >> >>Exactly why do people like the stack to dump?
    > >>
    > >> Some routines you will know where the stack came from, so it won't be

    > much
    > >> use. But if the routine that the error originated in is a very general

    > >routine
    > >> then the call could have come from a hundred places. Hence the call

    stack
    > >> will be useful.

    > >
    > >I'm not wondering so much why the stack is useful, but why would it be
    > >preferable to a call sequence log?
    > >
    > >I think a call sequence log shows where the call come from (the imediate
    > >stack), but it also shows info the stack doesn't.... the preceding calls
    > >that are no longer on the stack, and optionally any key state changes

    they
    > >made to the application that you log in passing.
    > >
    > >> One question I have regarding your approach. You call error handling

    code
    > >> to log each routine called before an error occurs. This means extra

    code
    > >> being run for every routine, and this extra code includes string

    > >manipulation
    > >> (which can be slow). Do you find this slows things down. Do you remove

    > it
    > >> from procs that are called repeatedly or have another method of dealing

    > >with
    > >> speed?

    > >
    > >One of my oldie sayings, "where efficiency matters, just measure
    > >efficiency". Don't ever cut back on maintainability or standards because
    > >somebody says variants, or strings, or anything else in the toolbag, are
    > >"too slow for a pro".
    > >
    > >Cut back ONLY when you have proof it IS faster in your program, and
    > >significantly faster. Line Numbers: Adding line numbers may "bloat" your
    > >code by 15-20% if you do the entire program. For a corp desktop/LAN app,

    > no
    > >problem.
    > >
    > >(Different story on web apps, where the CPU and memory may be shared for
    > >many users!)
    > >
    > >Say in another app you are looping100,000 times in some code, you

    probably
    > >wouldn't log every loop. It's too much info anyway! My "ring"

    structure
    > >log usually is initialized at 1000 items, after which older items

    overwrite.
    > >(The log that dumps on an error). There should be enough info in the

    last
    > >1000 messages to figure anything out, particularly when line numbers are
    > >there too.
    > >
    > >Any little tricks you find useful in error handling?
    > >
    > >regards
    > >Richard.
    > >
    > >

    >




  4. #49
    Mike Culley Guest

    Re: Correct Error Handling


    I'm not sure why you are getting annoyed over this issue - i didn't think
    I was impolite in my post.

    I think you misunderstand my statement

    >> this make the app generally quicker - even if there is no speed issue


    If something takes half a second to happen compared to a quarter of a second,
    wouldn't it be better that it takes a quarter? Sure half a second is good
    enough so there is no speed issue, but a quarter would be better. This would
    mean that it may run OK on a p66 instead of a p100. No big deal, but the
    quicker the better.

    Your method is going to be slower, but the call stack method gives less info
    in the case of an error. It is a tradoff - some may chose one method, some
    may chose another. I am just saying that I would chose the faster, but that
    is just my opinion. You are free to have yours.

    Michael Culley


    "Richard Curzon" <richardcurzon@home.com> wrote:
    >Mike Culley <m_culley@one.net.au> wrote in message
    >news:39209847$1@news.devx.com...
    >
    >Well, thank you, Exhibit A. I confess no matter how often I hear them ,

    I'm
    >slightly amazed when I read statements like
    >
    >> this make the app generally quicker - even if there is no speed issue

    >
    >but thankyou, because I know you are speaking for the majority!
    >
    >Very little of what goes on in a typical programmers head has any
    >tracability to the requirements, nor does it show any thorough knowledge

    of
    >the tool.
    >
    >We would be humiliated if our peers caught us using a variant, so we avoid
    >variants. Even if there is a good reason, e.g. ability to hold a Null when
    >dealing with a database, and there is no measurable speed cost.
    >
    >So it happens, we can actually say these things to each other "I do that
    >for speed, even though it has no measurable effect on speed":
    >
    >It isn't only VB programmers who don't think, it's everywhere... <grumble
    >grumble>
    >
    >regards
    >Richard.
    >
    >> Richard,
    >>
    >> I understand what you are saying, but I would not use your method. It

    only
    >> my way of coding, but I try to code as efficiently as possible from the

    >start,
    >> this make the app generally quicker - even if there is no speed issue

    it
    >> is better to have it run faster.
    >>
    >> Generally, I can find the error with just a call stack, or just the error
    >> and location. It may be harder to find, but that is a tradeoff.
    >>
    >> Michael Culley
    >>
    >> "Richard Curzon" <richardcurzon@home.com> wrote:
    >> >
    >> >Michael Culley <m_culley@one.net.au> wrote in message
    >> >news:391ea4a5$1@news.devx.com...
    >> >>
    >> >> Richard
    >> >>
    >> >> >>Exactly why do people like the stack to dump?
    >> >>
    >> >> Some routines you will know where the stack came from, so it won't

    be
    >> much
    >> >> use. But if the routine that the error originated in is a very general
    >> >routine
    >> >> then the call could have come from a hundred places. Hence the call

    >stack
    >> >> will be useful.
    >> >
    >> >I'm not wondering so much why the stack is useful, but why would it be
    >> >preferable to a call sequence log?
    >> >
    >> >I think a call sequence log shows where the call come from (the imediate
    >> >stack), but it also shows info the stack doesn't.... the preceding calls
    >> >that are no longer on the stack, and optionally any key state changes

    >they
    >> >made to the application that you log in passing.
    >> >
    >> >> One question I have regarding your approach. You call error handling

    >code
    >> >> to log each routine called before an error occurs. This means extra

    >code
    >> >> being run for every routine, and this extra code includes string
    >> >manipulation
    >> >> (which can be slow). Do you find this slows things down. Do you remove

    >> it
    >> >> from procs that are called repeatedly or have another method of dealing
    >> >with
    >> >> speed?
    >> >
    >> >One of my oldie sayings, "where efficiency matters, just measure
    >> >efficiency". Don't ever cut back on maintainability or standards because
    >> >somebody says variants, or strings, or anything else in the toolbag,

    are
    >> >"too slow for a pro".
    >> >
    >> >Cut back ONLY when you have proof it IS faster in your program, and
    >> >significantly faster. Line Numbers: Adding line numbers may "bloat"

    your
    >> >code by 15-20% if you do the entire program. For a corp desktop/LAN

    app,
    >> no
    >> >problem.
    >> >
    >> >(Different story on web apps, where the CPU and memory may be shared

    for
    >> >many users!)
    >> >
    >> >Say in another app you are looping100,000 times in some code, you

    >probably
    >> >wouldn't log every loop. It's too much info anyway! My "ring"

    >structure
    >> >log usually is initialized at 1000 items, after which older items

    >overwrite.
    >> >(The log that dumps on an error). There should be enough info in the

    >last
    >> >1000 messages to figure anything out, particularly when line numbers

    are
    >> >there too.
    >> >
    >> >Any little tricks you find useful in error handling?
    >> >
    >> >regards
    >> >Richard.
    >> >
    >> >

    >>

    >
    >



  5. #50
    Anthony Jones Guest

    Re: Correct Error Handling

    >>
    If something takes half a second to happen compared to a quarter of a
    second,
    wouldn't it be better that it takes a quarter?
    <<

    Yes it would be better even when speed wasn't important. Unless it makes
    the code harder to read or in any other way negatively effect it's
    maintainability. Especially if others might need to maintain the code in
    the future or even you might be asked to maintain it after several months
    or even years. Bearing in mind also that another developer may not be as
    familiar with the technique.

    It's also a good idea to keep the code as simple and as close to the
    logical problem as possible. This keeps the bug count as low 'as possible
    from the start'. Unfortunately this philosophy is often at odds with 'code
    as efficiently as possible from the start'.

    --
    Anthony Jones
    Secta Group Ltd




  6. #51
    Richard Curzon Guest

    Re: Correct Error Handling


    Mike Culley <m_culley@one.net.au> wrote in message
    news:39261be6$1@news.devx.com...
    >
    > I'm not sure why you are getting annoyed over this issue - i didn't think
    > I was impolite in my post.
    >
    > I think you misunderstand my statement
    >
    > >> this make the app generally quicker - even if there is no speed issue

    >
    > If something takes half a second to happen compared to a quarter of a

    second,
    > wouldn't it be better that it takes a quarter? Sure half a second is good
    > enough so there is no speed issue, but a quarter would be better. This

    would
    > mean that it may run OK on a p66 instead of a p100. No big deal, but the
    > quicker the better.


    Mike, I hope you don't think using a long instead of a variant will save you
    half a second? .

    With a few lines you can add accurate millisecond timing to your apps. No
    programmer of real world applications should every build a system without
    it.

    I have not seen a case where using a variant made any measurable difference
    even at the hundredths of a second level, in any typical subroutine in a
    typical runtime environment.

    Using variants where they are useful (yes they are there for a reason!) has
    saved me many extra lines of awkward code. It has saved me from writing 5
    routines each for a different strong data type many times, unnecessary
    trapping for null errors, etc. And kept the system simpler, easier to debug
    and maintain.

    But my message isn't "use variants and thumb your nose at authority". It's
    to throw out superstition, measure what matters instead.

    And the real benefit of timing your apps is not to overcome the taboos,
    forget them. It's tracability and accountability in app performance.

    You will be able to tell your clients "A full 3 seconds of the form load
    time is due to your requirement for up-to-second data, If you step the
    requirement back a bit, your form will load 3 seconds faster. Other than
    that, the only significant block is the mainframe customer database call to
    tell us the current customer address. Do we really need the address on this
    form? ". Not just, "We don't use variants, so every thing works as fast
    as possible".

    You'll never look back, believe me.

    regards
    Richard.



  7. #52
    Mike Culley Guest

    Re: Correct Error Handling


    Richard,

    Where did the variants come from? I thought this discussion was about error
    handling. I use variants when I have to, but they are significantly slower.
    I'm not sure how you were timing them, but I timed them as being 12.5 times
    slower than a long. Thats 12.5 times - that is huge!

    >Mike, I hope you don't think using a long instead of a variant will save

    you
    >half a second? .


    In many cases (say a sorting routine) this is small in comparison to what
    you could save.

    No wonder we need pentium 300s or more to run standard business apps these
    days.

    Michael Culley


    "Richard Curzon" <richardcurzon@home.com> wrote:
    >
    >Mike Culley <m_culley@one.net.au> wrote in message
    >news:39261be6$1@news.devx.com...
    >>
    >> I'm not sure why you are getting annoyed over this issue - i didn't think
    >> I was impolite in my post.
    >>
    >> I think you misunderstand my statement
    >>
    >> >> this make the app generally quicker - even if there is no speed issue

    >>
    >> If something takes half a second to happen compared to a quarter of a

    >second,
    >> wouldn't it be better that it takes a quarter? Sure half a second is good
    >> enough so there is no speed issue, but a quarter would be better. This

    >would
    >> mean that it may run OK on a p66 instead of a p100. No big deal, but the
    >> quicker the better.

    >
    >Mike, I hope you don't think using a long instead of a variant will save

    you
    >half a second? .
    >
    >With a few lines you can add accurate millisecond timing to your apps.

    No
    >programmer of real world applications should every build a system without
    >it.
    >
    >I have not seen a case where using a variant made any measurable difference
    >even at the hundredths of a second level, in any typical subroutine in a
    >typical runtime environment.
    >
    >Using variants where they are useful (yes they are there for a reason!)

    has
    >saved me many extra lines of awkward code. It has saved me from writing

    5
    >routines each for a different strong data type many times, unnecessary
    >trapping for null errors, etc. And kept the system simpler, easier to debug
    >and maintain.
    >
    >But my message isn't "use variants and thumb your nose at authority". It's
    >to throw out superstition, measure what matters instead.
    >
    >And the real benefit of timing your apps is not to overcome the taboos,
    >forget them. It's tracability and accountability in app performance.
    >
    >You will be able to tell your clients "A full 3 seconds of the form load
    >time is due to your requirement for up-to-second data, If you step the
    >requirement back a bit, your form will load 3 seconds faster. Other than
    >that, the only significant block is the mainframe customer database call

    to
    >tell us the current customer address. Do we really need the address on

    this
    >form? ". Not just, "We don't use variants, so every thing works as fast
    >as possible".
    >
    >You'll never look back, believe me.
    >
    >regards
    >Richard.
    >
    >



  8. #53
    Richard Curzon Guest

    Re: Correct Error Handling


    Mike Culley <m_culley@one.net.au> wrote in message
    news:392721df$1@news.devx.com...
    >
    > Richard,
    > Where did the variants come from? I thought this discussion was about

    error
    > handling. I use variants when I have to, but they are significantly

    slower.
    > I'm not sure how you were timing them, but I timed them as being 12.5

    times
    > slower than a long. Thats 12.5 times - that is huge!


    To repeat:
    >> But my message isn't "use variants and thumb your nose at authority".

    It's
    >> to throw out superstition, measure what matters instead.


    Can't disappoint the customers by missing the standard answer -- "12.5 TIMES
    NOTHING IS .... NOTHING!" <grin>

    This may not apply to you Mike, although it sounds like it does.

    One more way to put it, it is a tangent. But is is such a pervasive
    stupidity in the VB world, I partly blame Fawcette mags for perpetuating it.
    (see if THAT starts a tangent)

    IMO, there are legions of VB programmers haven't quite grown up to the task
    in front of them. They are stuck on some romantic image of the VB corporate
    programmer as F1 driver. The basic code of honor is some easy stuff, like
    "never use variants".. Bbut basically trying to mystify the other ordinary
    programmers... nothing more satisfying than hearing them say "Wow, how did
    you do that?".

    They are reluctant to attend to the details that matter in their real world
    jobs. Way too boring!

    They're like the surbuban hubby who roars out in the family van on Saturday
    thinking like a Formula 1 driver. Out of site of wifey, who thinks they are
    getting tools to fix the patio, or weed killer! Not our hero. <grin>

    Corporate programmers should forget the irrelevant romantic illusion of
    "pedal to the metal" on every line of code, showing some killer style to
    mystify mere mortals. It's a time wasting fantasy, every day you are
    focussed on things that don't help the task or your customers. To the
    exclusion of the things that actually could help.

    A good VB programmer often says stuff like this:
    "Look at this performance log. The form takes 5 seconds to load because
    right here it takes 3 seconds to call the back end, just so we can show the
    current address. Drop the requirement, and we'll show the form 3 seconds
    faster."

    A lousy VB programmer often says stuff like this:
    "You used a variant here. No wonder the form load is so slow. And if it's
    still slow, that's all we can do".

    In my experience, once you get people started focussing on the things that
    REALLY matter, they never go back to the fantasy image of VB programmer as
    F1 driver! End of sidetrack for me!

    regards
    Richard the curmudgeon.



  9. #54
    Mike Culley Guest

    Re: Correct Error Handling


    Richard,

    I don't get it. I try to use variants less often and now I think I am a formula
    1 driver?

    I don't go right out of my way to avoid them. If it going to be a big hassle
    I will use them, but generally avoid them where possible.

    You seam to be forgetting the other reason not to use variant - they can
    introduce bugs. I had a situation where I was using a variant to store the
    return value from a recordset. It turned out that somehow the variant was
    storing a reference to the field, not the value as I wanted. Everytime I
    referenced the field I got the default value, hence it worked as if it had
    the value in it. This was most likely my fault, but if I had used a long
    or string etc it would not have happened.

    Personally, I think that they make programming harder in a lot of situation
    because you have more to worry about - is this a string or a long or something
    else. If it is a long you know what you have got.

    Michael Culley

    "Richard Curzon" <richardcurzon@home.com> wrote:
    >
    >Mike Culley <m_culley@one.net.au> wrote in message
    >news:392721df$1@news.devx.com...
    >>
    >> Richard,
    >> Where did the variants come from? I thought this discussion was about

    >error
    >> handling. I use variants when I have to, but they are significantly

    >slower.
    >> I'm not sure how you were timing them, but I timed them as being 12.5

    >times
    >> slower than a long. Thats 12.5 times - that is huge!

    >
    >To repeat:
    >>> But my message isn't "use variants and thumb your nose at authority".

    >It's
    >>> to throw out superstition, measure what matters instead.

    >
    >Can't disappoint the customers by missing the standard answer -- "12.5 TIMES
    >NOTHING IS .... NOTHING!" <grin>
    >
    >This may not apply to you Mike, although it sounds like it does.
    >
    >One more way to put it, it is a tangent. But is is such a pervasive
    >stupidity in the VB world, I partly blame Fawcette mags for perpetuating

    it.
    >(see if THAT starts a tangent)
    >
    >IMO, there are legions of VB programmers haven't quite grown up to the task
    >in front of them. They are stuck on some romantic image of the VB corporate
    >programmer as F1 driver. The basic code of honor is some easy stuff, like
    >"never use variants".. Bbut basically trying to mystify the other ordinary
    >programmers... nothing more satisfying than hearing them say "Wow, how did
    >you do that?".
    >
    >They are reluctant to attend to the details that matter in their real world
    >jobs. Way too boring!
    >
    >They're like the surbuban hubby who roars out in the family van on Saturday
    >thinking like a Formula 1 driver. Out of site of wifey, who thinks they

    are
    >getting tools to fix the patio, or weed killer! Not our hero. <grin>
    >
    >Corporate programmers should forget the irrelevant romantic illusion of
    >"pedal to the metal" on every line of code, showing some killer style to
    >mystify mere mortals. It's a time wasting fantasy, every day you are
    >focussed on things that don't help the task or your customers. To the
    >exclusion of the things that actually could help.
    >
    >A good VB programmer often says stuff like this:
    >"Look at this performance log. The form takes 5 seconds to load because
    >right here it takes 3 seconds to call the back end, just so we can show

    the
    >current address. Drop the requirement, and we'll show the form 3 seconds
    >faster."
    >
    >A lousy VB programmer often says stuff like this:
    >"You used a variant here. No wonder the form load is so slow. And if it's
    >still slow, that's all we can do".
    >
    >In my experience, once you get people started focussing on the things that
    >REALLY matter, they never go back to the fantasy image of VB programmer

    as
    >F1 driver! End of sidetrack for me!
    >
    >regards
    >Richard the curmudgeon.
    >
    >



  10. #55
    L.J. Johnson Guest

    Re: Correct Error Handling

    Mike,

    I'm looking at Richard and your messages, and I get the idea that ya'll are
    talking right past each other...

    Richard's point, if I can paraphrase, is in three parts:

    (1) Code for readability and functionality first
    (2) Optimize only the things (based on testing and *exact* timings) that
    *need* to be optimized.
    (3) Rules of thumb are exactly that -- things that apply 70%+ of the time,
    but not hard-and-fast rules

    Now, of course, it isn't to say you shouldn't use common sense. Certain
    things are up in the 95% range, like "reducing the number of network round
    trips on a n-tier app is a good thing". But even this "rule" can and should
    be broken, occasionally, for very specific reasons.

    I used to be one of those people that *never* used variants, and I
    considered variants pure evil. And, in many cases, they were. But using
    variants for dates, for example, is something I do all the time now. And,
    because I have to, variants is what I use for any objects that need to
    return info to vbscript. There are other good uses for variants, and Richard
    has pointed out a couple (like easier polymorphic behavior).

    Even the evil "End" statement, which is the exact wrong thing to use in
    99.9999% of the cases, has a use in rare cases (cases where you might
    otherwise wind up killing the app from the task manager). I had one of those
    programs a couple of years back.

    The point is, there is a use for *almost* everything, given a particular set
    of circumstances. And, the point is, pre-optimizing based on rules of thumb
    is not necessarily a good thing, and may even be a bad thing. Steve
    McConnell's books cover this in some detail.
    --
    L.J. Johnson, Slightly Tilted Software
    Microsoft MVP (Visual Basic)
    LJJohnsn@Flash.Net or LJJohnson@mvps.org
    <http://www.flash.net/~ljjohnsn>
    Ask The NT Pro at <http://www.inquiry.com>




  11. #56
    Mike Culley Guest

    Re: Correct Error Handling


    But the point is I do use variants - when I have to. I found your post re
    dates interesting because this is one of the cases where I use variants ie
    you usually need a null for dates. In the case of an amount I would use a
    double/currency because I usually don't need a null (eg amount paid = null).

    But on the other hand, I will go to a little extra effort to avoid them when
    required.

    Michael Culley

    "L.J. Johnson" <ljjohnsn@flash.net> wrote:
    >Mike,
    >
    >I'm looking at Richard and your messages, and I get the idea that ya'll

    are
    >talking right past each other...
    >
    >Richard's point, if I can paraphrase, is in three parts:
    >
    >(1) Code for readability and functionality first
    >(2) Optimize only the things (based on testing and *exact* timings) that
    >*need* to be optimized.
    >(3) Rules of thumb are exactly that -- things that apply 70%+ of the time,
    >but not hard-and-fast rules
    >
    >Now, of course, it isn't to say you shouldn't use common sense. Certain
    >things are up in the 95% range, like "reducing the number of network round
    >trips on a n-tier app is a good thing". But even this "rule" can and should
    >be broken, occasionally, for very specific reasons.
    >
    >I used to be one of those people that *never* used variants, and I
    >considered variants pure evil. And, in many cases, they were. But using
    >variants for dates, for example, is something I do all the time now. And,
    >because I have to, variants is what I use for any objects that need to
    >return info to vbscript. There are other good uses for variants, and Richard
    >has pointed out a couple (like easier polymorphic behavior).
    >
    >Even the evil "End" statement, which is the exact wrong thing to use in
    >99.9999% of the cases, has a use in rare cases (cases where you might
    >otherwise wind up killing the app from the task manager). I had one of those
    >programs a couple of years back.
    >
    >The point is, there is a use for *almost* everything, given a particular

    set
    >of circumstances. And, the point is, pre-optimizing based on rules of thumb
    >is not necessarily a good thing, and may even be a bad thing. Steve
    >McConnell's books cover this in some detail.
    >--
    >L.J. Johnson, Slightly Tilted Software
    >Microsoft MVP (Visual Basic)
    >LJJohnsn@Flash.Net or LJJohnson@mvps.org
    ><http://www.flash.net/~ljjohnsn>
    >Ask The NT Pro at <http://www.inquiry.com>
    >
    >
    >



  12. #57
    Mike Culley Guest

    Re: Correct Error Handling


    Oops, that should have read:

    (eg amount paid = 0)

    "Mike Culley" <m_culley@one.net.au> wrote:
    >
    >But the point is I do use variants - when I have to. I found your post re
    >dates interesting because this is one of the cases where I use variants

    ie
    >you usually need a null for dates. In the case of an amount I would use

    a
    >double/currency because I usually don't need a null (eg amount paid = null).
    >
    >But on the other hand, I will go to a little extra effort to avoid them

    when
    >required.
    >
    >Michael Culley
    >
    >"L.J. Johnson" <ljjohnsn@flash.net> wrote:
    >>Mike,
    >>
    >>I'm looking at Richard and your messages, and I get the idea that ya'll

    >are
    >>talking right past each other...
    >>
    >>Richard's point, if I can paraphrase, is in three parts:
    >>
    >>(1) Code for readability and functionality first
    >>(2) Optimize only the things (based on testing and *exact* timings) that
    >>*need* to be optimized.
    >>(3) Rules of thumb are exactly that -- things that apply 70%+ of the time,
    >>but not hard-and-fast rules
    >>
    >>Now, of course, it isn't to say you shouldn't use common sense. Certain
    >>things are up in the 95% range, like "reducing the number of network round
    >>trips on a n-tier app is a good thing". But even this "rule" can and should
    >>be broken, occasionally, for very specific reasons.
    >>
    >>I used to be one of those people that *never* used variants, and I
    >>considered variants pure evil. And, in many cases, they were. But using
    >>variants for dates, for example, is something I do all the time now. And,
    >>because I have to, variants is what I use for any objects that need to
    >>return info to vbscript. There are other good uses for variants, and Richard
    >>has pointed out a couple (like easier polymorphic behavior).
    >>
    >>Even the evil "End" statement, which is the exact wrong thing to use in
    >>99.9999% of the cases, has a use in rare cases (cases where you might
    >>otherwise wind up killing the app from the task manager). I had one of

    those
    >>programs a couple of years back.
    >>
    >>The point is, there is a use for *almost* everything, given a particular

    >set
    >>of circumstances. And, the point is, pre-optimizing based on rules of thumb
    >>is not necessarily a good thing, and may even be a bad thing. Steve
    >>McConnell's books cover this in some detail.
    >>--
    >>L.J. Johnson, Slightly Tilted Software
    >>Microsoft MVP (Visual Basic)
    >>LJJohnsn@Flash.Net or LJJohnson@mvps.org
    >><http://www.flash.net/~ljjohnsn>
    >>Ask The NT Pro at <http://www.inquiry.com>
    >>
    >>
    >>

    >



  13. #58
    Kathleen Dollard-Joeris Guest

    Re: Correct Error Handling

    Ronald,

    I haven't used them enough. There are aspects I really like, including
    reverse engineering. We do a crappy job of documenting projects, and it
    certainly looks good to build the diagrams and other boring stuff
    automatically.

    But I really hate code generation, and where it does that I am a little
    hesitant. But it's purpose is broader, so I am maintaining an open mind
    until I work with it more.

    --
    Kathleen
    (MS-MVP)
    Reply in the newsgroup so everyone can benefit
    --



  14. #59
    Kathleen Dollard-Joeris Guest

    Re: Correct Error Handling

    Richard,

    You're no fun! We always wind up agreeing more than not.

    OK, if I get time I am going to write an addin that does my comment block,
    cursor and logging. But I want it all in the language. All of it! Including
    a special block that does the default, description crap! I want like a
    little form that is always in the code (screen and printed) that I design
    with checkboxes and combos that automatically appears in the editor when I
    type Function or Sub.

    Of course, in the meantime I will do my little Ctl-C/Ctl-V meditation, which
    is just the human code generator, so I hate it.

    --
    Kathleen
    (MS-MVP)
    Reply in the newsgroup so everyone can benefit
    --



  15. #60
    Liam Grossmann Guest

    Re: Correct Error Handling


    Kathleen,

    the code generators that are available today can be great time savers and
    can cut costs dramatically. Coding all your SQL, stored procedures, database
    access classes and error handling from scratch takes ages. Generators can
    also be used as great training tools for new developers.

    For example, in the case of web page creation, do you think that FrontPage
    is a useful tool? I do and so do a lot of other people that use it to generate
    HTML.

    VB itself ships with a lot of useful wizards and templates that generate
    code for you. SQL-Server ships with options to automatically generate stored
    procedures.

    In the case of VB, I use a generator called VBeXpress. OK ... I wrote it
    and I am biased .... but I couldn't do without it and neither could a lot
    of my customers.

    Liam
    http://www.vbexpress.com


    "Kathleen Dollard-Joeris" <kjoeris@noemailplease.com> wrote:
    >Ronald,
    >
    >I haven't used them enough. There are aspects I really like, including
    >reverse engineering. We do a crappy job of documenting projects, and it
    >certainly looks good to build the diagrams and other boring stuff
    >automatically.
    >
    >But I really hate code generation, and where it does that I am a little
    >hesitant. But it's purpose is broader, so I am maintaining an open mind
    >until I work with it more.
    >
    >--
    >Kathleen
    >(MS-MVP)
    >Reply in the newsgroup so everyone can benefit
    >--
    >
    >



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center