The Pragmatic Programmer - How to use Exceptions

After 112 episodes, Michael can’t introduce the show, Allen pronounces it “ma-meee”, and don’t make Joe run your janky tests as The Pragmatic Programmer teaches us how we should use exceptions and program deliberately.

How are you reading this? If you answered via your podcast player, you can find this episode’s full show notes and join the conversation at https://www.codingblocks.net/episode113.

 

Sponsors

• Datadog.com/codingblocks – Sign up today for a free 14 day trial and get a free Datadog t-shirt after creating your first dashboard.

Survey Says …

When you want to bring in a new technology or take a new approach when implementing something new or add to the tech stack, do you ...?

Take the survey here:
https://www.codingblocks.net/episode113

 

News

• Thank you for taking a moment out of your day to leave us a review.
  • iTunes: MatteKarla, WinnerOfTheRaceCondition, michael_mancuso
  • Stitcher: rundevcycle, Canmichaelpronouncethis, WinnerOfTheRaceCondition, C_Flat_Fella, UncleBobsNephew, alexUnique
• Autonomous ErgoChair 2 Review (YouTube)
• Come see us Saturday, September 14, 2019 at the Atlanta Code Camp 2019 (atlantacodecamp.com)
• Are they cakes, cookies, or biscuits? (Wikipedia)

Intentional Code

When to use Exceptions

• In an earlier chapter, Dead Programs Tell No Lies, the book recommends:
  • Checking for every possible error.
  • Favor crashing your program over running into an inconsistent state.
• This can get really ugly! Especially if you believe in the “one return at the bottom” methodology for your methods.
• You can accomplish the same thing by just catching an exception for a block of code, and throwing your own with additional information.
• This is nice, but it brings up the question? When should you return a failed status, and when should you throw an exception?
• Do you tend to throw more exceptions in one layer more than another, such as throwing more in your C# layer than your JS layer?
• The authors advise throwing exceptions for unexpected events.
• Ask yourself, will the code still work if I remove the exception handlers? If you answered “no”, then maybe your throwing exceptions for non-exceptional circumstances.

Tip 34

• Use exceptions for exceptional problems

Exceptions vs Error Handling

• Should you throw an exception if you try to open a file, and it doesn’t exist?
  • If it should be there, i.e. a config, yes, throw the exception.
  • If it might be OK for it not to be there, i.e. you’re polling for a file to be created, then no, you should handle the error condition.
• Is it dangerous to rely on implicit exception throwing, i.e. opening a file that isn’t there?
  • On the one hand, it’s cleaner without checking for the exceptions, but there’s no signaling to your co-coders that you did this intentionally.
  • Exceptions are a kind of coupling because they break the normal input/output contract.
• Some languages / frameworks allow you to register error handlers that are outside the flow of the normal problem.
  • This is great for certain types of problems, like serialization problems, particularly when there is a prescribed flow, such as error pages, serialization, or SSL errors.

Programming by Coincidence

• Wha