http://www.perlmonks.org?node_id=476192


in reply to Re^6: Perl Best Practices
in thread Perl Best Practices

In my experience, why an exception was thrown is rarely as important as that it was thrown.

That's absolutely right. However, if a particular exception is caught from a function you didn't anticipated, you may very well end with an incoherent state. Well, There's a nice article on this matter here : Exceptions and another one there which is even better :Cleaner, more elegant, and harder to recognize . I understand very well the way exceptions match the "laziness and hubris" state-of-mind, however I feel more like Joel on this ;)

Replies are listed 'Best First'.
Re^8: Perl Best Practices
by Anonymous Monk on Jul 19, 2005 at 17:55 UTC
    Am I the only one who thinks the linked articles make a better case against mutable state than exceptions?
      What do you mean? For me "mutable states" are stuff like loop indices. May you develop?
        From the articles...
        Every time you call a function that can raise an exception and don't catch it on the spot, you create opportunities for surprise bugs caused by functions that terminated abruptly, leaving data in an inconsistent state, or other code paths that you didn't think about.
        ...and...
        NotifyIcon CreateNotifyIcon() { NotifyIcon icon = new NotifyIcon(); icon.Text = "Blah blah blah"; icon.Visible = true; icon.Icon = new Icon(GetType(), "cool.ico"); return icon; }
        Here's what it might look like after you fix it to be correct in the face of exceptions:
        NotifyIcon CreateNotifyIcon() { NotifyIcon icon = new NotifyIcon(); icon.Text = "Blah blah blah"; icon.Icon = new Icon(GetType(), "cool.ico"); icon.Visible = true; return icon; }
        Note that the errors arise when the exception disrupts the sequencing of side effects. No side-effects (like state), no problems.