• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Best practice: proactively prevent a known error, deal with it when it happens, or both?

 
Ranch Hand
Posts: 239
12
Scala IntelliJ IDE Eclipse IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here's a question that may be more philosophical about how to code. Let's say you know a certain set of conditions can arise within a program leading to a runtime error like NullPointerException, and you have the option then to check for and deal with it at the place it might happen. At the same time, you could prevent these conditions from ever cropping up at all, if earlier on in the program you perform a certain action. Which choice do you choose and why? Doing both may be an answer, but it will clutter the code and could be overkill.

My opinion is leaning in the direction of prevention. At the same time, the problem with prevention is it seems impossible to know that you've actually prevented said conditions. What if you haven't thought of other ways it could happen?
 
Marshal
Posts: 79178
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Depends whether the error matters. The more it matters, the more you want to prevent it. NullPointerException (NPE) is maybe not the best example, because it is mostly caused by programming errors. You can prevent NPEs arising from objects of the Foo class like this:-You can use a set method without a defensive copy in this instance because String is immutable.

I would say, if the possibility of an error matters, do all you can to prevent it happening in the first place. Nice assertive defensive programming, throwing Exceptions where things go wrong.
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here's my opinion about a related problem.

Quite often in a GUI you have buttons which promise to perform actions on an underlying data store. For example you might have a "Delete" button which promises to delete the item selected in a list displayed just above. Often you'll find that clicking on that "Delete" button just produces a dialog which says "You can't delete that item". I find that irritating, so I try to write code which greys out the button if it isn't actually going to do anything.

However there are a couple of disadvantages of that: First your code has to figure out if the item can or cannot be deleted before displaying the button. If that's time-consuming then your GUI redisplay slows down and you may have used up that processor time for nothing. And second, if the button is greyed out then the user might reasonably ask "Why can't I delete this item?"
 
Ranch Hand
Posts: 35
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I generally favor prevention wherever practical, but it can be tricky to cover all scenarios. Consider Paul's example of a GUI with a grayed-out delete button in the context of a typical web application. You can render a web page dynamically and enable certain delete buttons while disabling others according to the business rules, and that will be sufficient to safeguard against your typical, benign user. However, an unethical person could use a tool like Fiddler to generate practically any HTTP request imaginable including the one that would be sent if the user were able to click one of the disabled delete buttons. The server-side portion of the application can never trust the client: even though it just sent a page to the client that should prevent the user from deleting item #123 the very next HTTP request it handles could be one targeting the deletion of item #123. You have to implement these safeguards on the server too- that's where the buck really stops.
 
reply
    Bookmark Topic Watch Topic
  • New Topic