Do or not do. There is no try.



  • Good advice from Yoda. Check this code I found when refactoring some related area of our app.  The developer clearly does not know what to do about exceptions.  This method seems to be initializing the object and returning true or false (for no particular reason).   I love how he happily continues on even if an exception occurs. Also note the use of a default exception handler which does nothing except hide the exceptions. The saddest part of course is the calling code handles the exceptions so he shouldn't be trying anything here at all.

     

     private boolean setCurrentFeesAndOldAndNewExamTriggers() {
          try {
             newStatusValue = (ExamStatusValue) ExamStatusFactory.getInstance()
                     .getValueObject(newExamValue.getExamStatusNo());
          } catch (BadDataException e) {
             e.printStackTrace();  //To change body of catch statement use File | Settings | File Templates.
             return true;
          }
          try {
             oldStatusValue = (ExamStatusValue) ExamStatusFactory.getInstance()
                     .getValueObject(oldExamValue.getExamStatusNo());
          } catch (BadDataException e) {
             e.printStackTrace();  //To change body of catch statement use File | Settings | File Templates.
             return true;
          }
          //If no change done or type, for some reason is higher than what we
          // currently handle, return.
          SystemPropertyUtil propertyUtil = SystemPropertyUtil.getInstance();
          sendSupplyFees = WhenToSendBilling.get(String.valueOf(
                  propertyUtil.getWhenToSendSupplyFees()));
          sendTechnicalFees = WhenToSendBilling.get(String.valueOf(
                  propertyUtil.getWhenToSendTechnicalFees()));
          sendProfessionalFees = WhenToSendBilling.get(String.valueOf(
                  propertyUtil.getWhenToSendProfessionalFees()));

          if (sendTechnicalFees == WhenToSendBilling.Never
                  && sendSupplyFees == WhenToSendBilling.Never
                  && sendProfessionalFees == WhenToSendBilling.Never) {
             return true;
          }

          correctionsToExamTriggerCreditsAndNewCharges
                  = propertyUtil.isCorrectionsToExamWillTriggerCreditsAndNewCharges();
          autoApproveIfPassesValidation
                  = propertyUtil.isAutoApproveIfPassesValidation();
          if (formerBillingMethod.isExportingNoTypeOfFee() && newBillingMethod.isExportingNoTypeOfFee()) {
             //Assuming that the billing method is updatable only within
             // EXAM_EDIT_UPDATE originating action.
             return true;
          }

          endExamStatus = 0;
          try {
             endExamStatus = Integer.parseInt(SystemPropertyUtil.getInstance().getEndExamStatus());
          } catch (NumberFormatException e) {
             e.printStackTrace();  //To change body of catch statement use File | Settings | File Templates.
             return true;
          }

          try {
             neverRequiresInterpretationExamStatusNo = SystemPropertyUtil.
                     getInstance().getExamStatusNoForNeverRequiresInterpretation();
          } catch (NumberFormatException e) {
             e.printStackTrace();  //To change body of catch statement use File | Settings | File Templates.
             return true;
          }

          currentBillingFeesInterface = new BillingFeesInfo(newExamValue.getExamId(),
                  contextInfo);

          setExamBillingTrigger(true);
          setExamBillingTrigger(false);
          return false;
       } 



  • @sproketboy said:

    //To change body of catch statement use File | Settings | File Templates.

    Whaaat? Theeeee? Eff?

    @sproketboy said:

    setExamBillingTrigger(true);
    setExamBillingTrigger(false);

    ROFLMAO! This!

    I also love how this guy wrote back-to-back try/catch blocks looking for the same exception; first was BadDataException, and last was the NumberFormatException. I guess it never occurred to them to combine them?

    [Not withstanding that, as you said, there is no need for try/catch since the caller handles that for him.]

    For me, an additional WTF is using e.printStackTrace() to just dumpify the exception stack trace without concern for where it might actually appear (or not appear). I tend to prefer to go the extra mile and use a PrintWriter to write the stack trace to a debug-specific log file. But, some people here might consider that a WTF unto itself. C'est la vie!



  • @dohpaz42 said:

    I tend to prefer to go the extra mile and use a PrintWriter to write the stack trace to a debug-specific log file. But, some people here might consider that a WTF unto itself. C'est la vie!
    Seems spot-on to me!



  • @hoodaticus said:

    @dohpaz42 said:
    I tend to prefer to go the extra mile and use a PrintWriter to write the stack trace to a debug-specific log file. But, some people here might consider that a WTF unto itself. C'est la vie!
    Seems spot-on to me!

    You guys don't use a full-blown logger in [i]every program you write[/i]?? Why not??

    log4j ftw!



  • @Xyro said:

    @hoodaticus said:
    @dohpaz42 said:
    I tend to prefer to go the extra mile and use a PrintWriter to write the stack trace to a debug-specific log file. But, some people here might consider that a WTF unto itself. C'est la vie!
    Seems spot-on to me!

    You guys don't use a full-blown logger in every program you write?? Why not??

    log4j ftw!

    haha. I know that you're joking, but I meant to explicitly state using the PrintWriter with a logger, but I ass-u-me'd that it was implied with the "debug-specific log file". Ooops on me. :)



  • @Xyro said:

    @hoodaticus said:
    @dohpaz42 said:
    I tend to prefer to go the extra mile and use a PrintWriter to write the stack trace to a debug-specific log file. But, some people here might consider that a WTF unto itself. C'est la vie!
    Seems spot-on to me!

    You guys don't use a full-blown logger in every program you write?? Why not??

    log4j ftw!

    There is no need for such things. Every mature organization has users and a ticket system to report important issues, and users will provide screenshots and error messages if they want something fixed. (As for the issues that users don't complain about, well, they are not issues.)



  • @thistooshallpass said:

    Threre is no need for such things. Every mature organization has users and a ticket system to report important issues, and users will provide screenshots and error messages if they want something fixed. (As for the issues that users don't complain about, well, they are not issues.)

    Can I get some of what you are smoking???



  • @thistooshallpass said:

    There is no need for such things. Every mature organization has users and a ticket system to report important issues, and users will provide screenshots and error messages if they want something fixed. (As for the issues that users don't complain about, well, they are not issues.)

    TRWTF are those users who send screenshots for EVERYTHING; especially errors that are of a generic "Something went wrong, try again later!" nature.



  • @dohpaz42 said:

    @thistooshallpass said:
    There is no need for such things. Every mature organization has users and a ticket system to report important issues, and users will provide screenshots and error messages if they want something fixed. (As for the issues that users don't complain about, well, they are not issues.)

    TRWTF are those users who send screenshots for EVERYTHING; especially errors that are of a generic "Something went wrong, try again later!" nature.

    When I worked at Xbox 360 game QA at Microsoft, there were some developers who insisted on this. (It helped that the XBox 360 dev kits make this a one-button-push operation.) I was involved in a bug with a group of developers named after the cord used in a sport involving jumping from bridges, who insisted we provide an image for the bug "the screen turns entirely black if X". We made the image in a paint program.



  • @dohpaz42 said:

    @Xyro said:
    You guys don't use a full-blown logger in every program you write?? Why not??

    log4j ftw!

    haha. I know that you're joking

    I was not joking :(

    @dohpaz42 said:

    TRWTF are those users who send screenshots for EVERYTHING; especially errors that are of a generic "Something went wrong, try again later!" nature.

    Especially when said screenshot is a full-screen bitmap embedded in a Word document attached to a email when the important content is of a simple text message. I DEAL WITH THIS EVER DAY >:O



  • @Xyro said:

    @dohpaz42 said:
    @Xyro said:
    You guys don't use a full-blown logger in every program you write?? Why not??

    log4j ftw!

    haha. I know that you're joking

    I was not joking :(

    It was a 50/50 guess really. The italics threw me off. Me and those damned assumptions again. :)

    @Xyro said:

    @dohpaz42 said:
    TRWTF are those users who send screenshots for EVERYTHING; especially errors that are of a generic "Something went wrong, try again later!" nature.

    Especially when said screenshot is a full-screen bitmap embedded in a Word document attached to a email when the important content is of a simple text message. I DEAL WITH THIS EVER DAY >:O

    Oh, god. I get those too. What's worse is that the people that I get them from use the latest and <sarcasm>greatest</sarcasm> version of Word, and I'm stuck with OpenOffice - which has a difficult time rendering images in a Word file. Go figure.



  • @TheCPUWizard said:

    @thistooshallpass said:

    Threre is no need for such things. Every mature organization has users and a ticket system to report important issues, and users will provide screenshots and error messages if they want something fixed. (As for the issues that users don't complain about, well, they are not issues.)

    Can I get some of what you are smoking???

    User-based debugging works pretty well. After a while if there are a lot of bugs in the software, some of the more skilled users will start to provide support to the others and help them work around the bugs. (It's important to reward those power users by providing them with a secret handshake, a 2$ keyring and a nice acronym, like, say, MVP).



  • @thistooshallpass said:

    User-based debugging works pretty well. After a while if there are a lot of bugs in the software, some of the more skilled users will start to provide support to the others and help them work around the bugs. (It's important to reward those power users by providing them with a secret handshake, a 2$ keyring and a nice acronym, like, say, MVP).

    Please remind me to NOT:

    1) Buy anything made by the company you work for.
    2) Never consider hiring you.

    Defects fall into two major categories. The first is where the product/program does something other than what it was designed to do [Implementation Error]. The second is where the program works as designed, but does not meet the users needs. While the second will invlove user-based-testing, it should still be performed before deployment.

    Defects are a FAIL, someone did not do their job right. Most of the programs my company develops have penalty clauses for bugs [the first cateogry of defects listed above] that can range from hundreds to tens of thousands of dollars per incident. User-based-testing could easily cost far more than the revenue provided by the product with only a handful of bugs detected.


  • ♿ (Parody)

    @TheCPUWizard said:

    Defects are a FAIL

    Especially when it's your sense of humor that's defective.



  •  @TheCPUWizard said:


    @thistooshallpass said:

    User-based debugging works pretty well. After a while if there are a lot of bugs in the software, some of the more skilled users will start to provide support to the others and help them work around the bugs. (It's important to reward those power users by providing them with a secret handshake, a 2$ keyring and a nice acronym, like, say, MVP).

    Please remind me to NOT:

    1) Buy anything made by the company you work for.
    2) Never consider hiring you.

     

    Well, thistooshalpass was probably joking,  but there are indeed times when delaying the software for testing will lead to so big costs that user-based debuging is the preferred option.



  • @dohpaz42 said:

    For me, an additional WTF is using e.printStackTrace() to just dumpify the exception stack trace without concern for where it might actually appear (or not appear).
    This isn't a real WTF. It is a consequence of the original coder not having "used File | Settings | File Templates to change body of catch statement".

    This was clearly code put there by the IDE, because it complained about uncaught exceptions, suggested surrounding the offending code with this boilerplate try-catch, and the WTFer blindly accepted the suggestion.

    Ok, so maybe it is a real WTF, but not in the way you may have thought.



  • @Zecc said:

    @dohpaz42 said:

    For me, an additional WTF is using e.printStackTrace() to just dumpify the exception stack trace without concern for where it might actually appear (or not appear).
    This isn't a real WTF. It is a consequence of the original coder not having "used File | Settings | File Templates to change body of catch statement".

    This was clearly code put there by the IDE, because it complained about uncaught exceptions, suggested surrounding the offending code with this boilerplate try-catch, and the WTFer blindly accepted the suggestion.

    Ok, so maybe it is a real WTF, but not in the way you may have thought.

    Oh you're right, on both accounts. I wasn't referring to the boilerplate code; I was making a conjecture on what the boilerplate code produced. In this case, those are two separate WTFs.



  • @Mcoder said:

    Well, thistooshalpass was probably joking,  but there are indeed times when delaying the software for testing will lead to so big costs that user-based debuging is the preferred option.

    Possibly (probably?) it was intended as a joke, but I disagree with your premise. Properly structured, there should never be "delaying the software for testing". As the code is written, all appropriate tests should be simultanously created; no code goes into the source control system that is not passing a validation suite. Once a person/team is in the habit, it is quite efficient - most that I work with keep two windows side by side in the IDE, writing the test as they write each line (or few lines) of code. The resulting code quality improvements almost invariably reduce the amount of time to implement a feature (fyi: big fan of feature driven development - if you structure your features correctly) yeielding either more features per iteration or shorter release cycles depending on how the cadence is structured.



  • @TheCPUWizard said:

    Possibly (probably?) it was intended as a joke, but I disagree with your premise. Properly structured, there should never be "delaying the software for testing". As the code is written, all appropriate tests should be simultanously created; no code goes into the source control system that is not passing a validation suite. Once a person/team is in the habit, it is quite efficient - most that I work with keep two windows side by side in the IDE, writing the test as they write each line (or few lines) of code. The resulting code quality improvements almost invariably reduce the amount of time to implement a feature (fyi: big fan of feature driven development - if you structure your features correctly) yeielding either more features per iteration or shorter release cycles depending on how the cadence is structured.

    Only a small subset of bugs can be caught in an automated fashion.


  • ♿ (Parody)

    @blakeyrat said:

    Only a small subset of bugs can be caught in an automated fashion.

    The size is debatable, but in my experience, automated tests are best / most useful for catching regressions.



  • @boomzilla said:

    @blakeyrat said:
    Only a small subset of bugs can be caught in an automated fashion.

    The size is debatable, but in my experience, automated tests are best / most useful for catching regressions.

    Typical automated tests will usually tell you if something does not work, not if it works. This is why stuff like executable specifications is great - it's TDD initiated by the SME/BA, not the programmer.



  • @boomzilla said:

    @blakeyrat said:
    Only a small subset of bugs can be caught in an automated fashion.

    The size is debatable, but in my experience, automated tests are best / most useful for catching regressions.

    Yeah, but my beefs:


    1) Developers writing as if automated testing is the be-all-end-all of all development QA needs ever

    2) Automated tests don't do much for the most important type of bugs, UI bugs


  • ♿ (Parody)

    @blakeyrat said:

    Yeah, but my beefs:


    1) Developers writing as if automated testing is the be-all-end-all of all development QA needs ever

    2) Automated tests don't do much for the most important type of bugs, UI bugs


    Totally agree with #1. LOL, UI bugs. Not that they aren't important, but silently and subtly corrupting data is much more serious. Or, even, loudly and obviously for that matter.


  • Garbage Person

     @boomzilla said:

    LOL, UI bugs. Not that they aren't important, but silently and subtly corrupting data is much more serious. Or, even, loudly and obviously for that matter.
    Data corruption will sink your product before it even ships - but UI bugs will sink customer opinion. Data bugs are cheap and easy to detect. UI bugs are much harder and more expensive. Therefore, assuming you do those cheap and easy things (automated testing), UI bugs are now more important as importance is relative to the level of risk presented.


  • ♿ (Parody)

    @Weng said:

    Data corruption will sink your product before it even ships - but UI bugs will sink customer opinion. Data bugs are cheap and easy to detect. UI bugs are much harder and more expensive. Therefore, assuming you do those cheap and easy things (automated testing), UI bugs are now more important as importance is relative to the level of risk presented.

    I definitely am not arguing that UI isn't important or anything. I suppose that if your data is pretty simple, like keeping track of orders or something, your statement is probably true. But with a very complex data model, or very complex behavior, it's really difficult to find all of the edge cases, and you never know when one of them will be immediately catastrophic, or just silently give you slight errors that build up over time until most of your data is corrupted or useless.



  • Many good points on testing, however I maintain that 99.99% can and should be automated. This does not mean *just* writing unit tests. Even when "QA" is running the application doing exploratory testing, there are plenty of good tools to record their action, the results and even the specific things they are looking at (visually). These recordings are then organized, placed in a repository and can then be run at will in a completely automatic fashion.

     Regarding "data" (which I agree is critical), there are algorithms to find the edge cases, as well as "fuzzing" algorithms that generate unique data based on variants of existing data. These tools will often discover many subtle issues (the issue may be subtle, but the result can be quite catastrophic). On most of my data-centric applications, I keep one machine (VM) running this type of testing 24/7 with alerts being distributed on any anomoly. This provides a much more comprehensive suite than could ever be accomplished manually.



  • @boomzilla said:

    @Weng said:
    Data corruption will sink your product before it even ships - but UI bugs will sink customer opinion. Data bugs are cheap and easy to detect. UI bugs are much harder and more expensive. Therefore, assuming you do those cheap and easy things (automated testing), UI bugs are now more important as importance is relative to the level of risk presented.

    I definitely am not arguing that UI isn't important or anything. I suppose that if your data is pretty simple, like keeping track of orders or something, your statement is probably true. But with a very complex data model, or very complex behavior, it's really difficult to find all of the edge cases, and you never know when one of them will be immediately catastrophic, or just silently give you slight errors that build up over time until most of your data is corrupted or useless.

     

    Both are equally important.



  •  

    setExamBillingTrigger(true);
    setExamBillingTrigger(false);
    LOL! I didn't notice that one. 

Log in to reply