Artwork

Content provided by iteration podcast, John Jacob, and JP Sio - Web Developers. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by iteration podcast, John Jacob, and JP Sio - Web Developers or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://ppacc.player.fm/legal.
Player FM - Podcast App
Go offline with the Player FM app!

Alternatives to Exceptions

40:10
 
Share
 

Manage episode 220247618 series 1900125
Content provided by iteration podcast, John Jacob, and JP Sio - Web Developers. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by iteration podcast, John Jacob, and JP Sio - Web Developers or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://ppacc.player.fm/legal.

Alternatives to Exceptions


  • Multiple return values in failures can be helpful -
  • Represent a process as an object “Download Provisionment” - This is a really interesting idea…. “MessageSend.new” - would actually handle a lot of the issues in the SMS interface concept we’ve been talking through.
  • “It’s tempting to raise an exception every time you get an answer you don’t like. But exception handling interrupts and obscures the flow of your business logic. Consider carefully whether a situation is truly unusual before raising an Exception.”
  • Diagnostics- don’t fail SO aggressively early that you don’t capture the diagnostics.

Examples of when to not "fail fast":

  1. test suites

Sometimes you just need a way to proceed through steps and have the system tell you what parts succeeded and what parts failed

Sideband data

When communication failures without resorting to exceptions, we need a sideband: a secondary channel of communication for reporting meta-information about the status and disposition of a process.

Multiple return values

hehe, this reminds me of stuff I do in javascript

  • ruby supports multiple return values in the form of array splatting. in JS, you could do this with destructuring

    def foo
    result = 42
    success = true
    [result, success]
    end

    result, success = foo
    puts "#{success ? 'succeeded' : 'failed'}; result #{result}"

Or you can use an open struct

def foo OpenStruct.new(:result => 42, :status => :success) end 

Output parameters

Caller-supplied fallback strategy

  • if we're not sure we want to terminate the execution of a long process by raising an exception, we can inject a failure policy into the process

    def make_user_accounts(host, failure_policy=method(:raise))
    # ...
    rescue => error
    failure_policy.call(error)
    end

    def provision_host(host, failure_policy)
    make_user_accounts(host, failure_policy)
    end

    policy = lambda { |e| puts e.message }
    provision_host("192.168.1.123", policy)

Picks

JP:

John:

Slack Video Calling + Collaboration

  continue reading

78 episodes

Artwork

Alternatives to Exceptions

iteration

113 subscribers

published

iconShare
 
Manage episode 220247618 series 1900125
Content provided by iteration podcast, John Jacob, and JP Sio - Web Developers. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by iteration podcast, John Jacob, and JP Sio - Web Developers or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://ppacc.player.fm/legal.

Alternatives to Exceptions


  • Multiple return values in failures can be helpful -
  • Represent a process as an object “Download Provisionment” - This is a really interesting idea…. “MessageSend.new” - would actually handle a lot of the issues in the SMS interface concept we’ve been talking through.
  • “It’s tempting to raise an exception every time you get an answer you don’t like. But exception handling interrupts and obscures the flow of your business logic. Consider carefully whether a situation is truly unusual before raising an Exception.”
  • Diagnostics- don’t fail SO aggressively early that you don’t capture the diagnostics.

Examples of when to not "fail fast":

  1. test suites

Sometimes you just need a way to proceed through steps and have the system tell you what parts succeeded and what parts failed

Sideband data

When communication failures without resorting to exceptions, we need a sideband: a secondary channel of communication for reporting meta-information about the status and disposition of a process.

Multiple return values

hehe, this reminds me of stuff I do in javascript

  • ruby supports multiple return values in the form of array splatting. in JS, you could do this with destructuring

    def foo
    result = 42
    success = true
    [result, success]
    end

    result, success = foo
    puts "#{success ? 'succeeded' : 'failed'}; result #{result}"

Or you can use an open struct

def foo OpenStruct.new(:result => 42, :status => :success) end 

Output parameters

Caller-supplied fallback strategy

  • if we're not sure we want to terminate the execution of a long process by raising an exception, we can inject a failure policy into the process

    def make_user_accounts(host, failure_policy=method(:raise))
    # ...
    rescue => error
    failure_policy.call(error)
    end

    def provision_host(host, failure_policy)
    make_user_accounts(host, failure_policy)
    end

    policy = lambda { |e| puts e.message }
    provision_host("192.168.1.123", policy)

Picks

JP:

John:

Slack Video Calling + Collaboration

  continue reading

78 episodes

All episodes

×
 
Loading …

Welcome to Player FM!

Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.

 

Quick Reference Guide

Copyright 2025 | Privacy Policy | Terms of Service | | Copyright
Listen to this show while you explore
Play