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. | [reply] [Watch: Dir/Any] [d/l] [select] |
Note that the errors arise when the exception disrupts the sequencing of side effects. No side-effects (like state), no problems.
All right. But AFAIK only pure functional programming avoids side-effects, isn't it? ;) How reimplementing the exemple above with no side-effects (in Perl, Java, Python, C++...) is beyond me.
| [reply] [Watch: Dir/Any] |
Well, when you write your own code in a language like Perl or Java, you can always try to minimize and localize side-effects. That is, you can try to make most of your functions pure, reduce the need for looping by using higher order functions, doing I/O at the top levels, not willy-nilly in the bowels, etc. When it comes to libraries though, you're at the mercy of someone else. Them's the breaks.
| [reply] [Watch: Dir/Any] |