4 ms·

"Can this method throw? Should I catch a PathTooLongException here? And while the .NET framework is documented to remarkable detail, this is rarely the case for

"Can this method throw? Should I catch a PathTooLongException here? And while the .NET framework is documented to remarkable detail, this is rarely the case for third-party libraries or in-house code. At the bottom of the call stack, you just have to assume everything may throw. " Isn't this true for all languages in one form or another? Go and Rust have "panics" Any code might fail exceptionally, stack overflows and out of memory conditions come to mind as relatively common ones. The difference here is that C# treats more kinds of things exceptionally than Rust or Go. This seems to have more to do with Rust and Go ability to more easily return multiple types from a method/function and a philosophy of opt-in vs opt-out on handling an error. I am used to C#/javascript so exceptions with try catch are very natural to me. Writing robust programs always involves handling everything one way or another. Even out of memory conditions can be handled and recovered if your always thinking that everything can throw. The null issue is interesting, I like null, I like undefined with null even better in javascript. I always seem to need to encode something has no value or something was never even set vs picking a valid value as a special "no value" i.e. int.MaxValue or whatever. The only thing I would change in C# and javascript is null lifting object.property should not throw if object is null same with foreach over null object. They are adding the ?. for that but you need to explicitly do it, NullReferenceException is far to common in C# from those two situations explicitly. I belive Objective-C did some kind of null lifting where sending messages to null objects don't throw.

masklinn 11y ago
> Isn't this true for all languages in one form or another? Go and Rust have "panics" Any code might fail exceptionally, stack overflows and out of memory conditions come to mind as relatively common ones. The concern does not make sense in Rust, Rust's panics can not be caught and will kill the current thread. > The difference here is that C# treats more kinds of things exceptionally than Rust or Go. Or it treats exceptions much less exceptionally than they do (Python being even further along on that axis), a C# exception is at best "uncommon". > This seems to have more to do with Rust and Go ability to more easily return multiple types from a method/function Rust doesn't use MRV for results, Result is a single struct (technically an enumerated type which can contain either a "valid result" or an "error result", not both). > I belive Objective-C did some kind of null lifting where sending messages to null objects don't throw. Not in the sense you think, Objective-C's nil is simply a black-hole, messages send to it don't do anything and return nil. It's possible (though not probably not recommended) to opt Smalltalk or Ruby[0] into this behaviour, because nil is a standard object not a magical special value (and both languages have open classes). [0] http://blog.rubyenrails.nl/articles/2008/02/29/our-daily-method-18-nilclass-method_missing http://blog.rubyenrails.nl/articles/2008/02/29/our-daily-met...
noelwelsh 11y ago
The issue is this: Things will go wrong. Some subset of things that can go wrong are things you want to do something about (e.g. file doesn't exist -- maybe prompt the user for a different file). The remainder are things you don't want to deal with (e.g. out of memory -- in most cases this is very rare so you're ok to just crash). You want to arrange your program in such a way that you must deal with the errors you want to deal with. Your code won't compile if you don't. That is what this technique brings. More here (though you probably won't understand many of the terms if you haven't used a modern FP-inspired language before): http://underscore.io/blog/posts/2015/02/23/designing-fail-fast-error-handling.html http://underscore.io/blog/posts/2015/02/23/designing-fail-fa...
- wvenable 11y ago
  > You want to arrange your program in such a way that you must deal with the errors you want to deal with. Which would be fine but there is no way to do that without also having being forced to deal with the infinite errors you don't want to deal with.
  - kibwen 11y ago
    If you don't want to deal with an error then you unwrap it, which will terminate your program just as well as an unhandled exception would. The salient difference is that you can't accidentally unwrap something, whereas you can accidentally forget to handle an exception.
    - wvenable 11y ago
      The set of exceptions that can be handled is vanishingly small. With exceptions you should be catching exceptions very infrequently and in key places. Talking about accidentally forgetting to handle an exception at a method-call site completely missed the point. That's not how one should code or think about coding when using exceptions.
  - noelwelsh 11y ago
    This is false. I use the pattern in the linked blog post everyday so that my code must deal with the errors I want to deal with and can ignore the rest.

masklinn 11y ago

> Isn't this true for all languages in one form or another? Go and Rust have "panics" Any code might fail exceptionally, stack overflows and out of memory conditions come to mind as relatively common ones. The concern does not make sense in Rust, Rust's panics can not be caught and will kill the current thread. > The difference here is that C# treats more kinds of things exceptionally than Rust or Go. Or it treats exceptions much less exceptionally than they do (Python being even further along on that axis), a C# exception is at best "uncommon". > This seems to have more to do with Rust and Go ability to more easily return multiple types from a method/function Rust doesn't use MRV for results, Result is a single struct (technically an enumerated type which can contain either a "valid result" or an "error result", not both). > I belive Objective-C did some kind of null lifting where sending messages to null objects don't throw. Not in the sense you think, Objective-C's nil is simply a black-hole, messages send to it don't do anything and return nil. It's possible (though not probably not recommended) to opt Smalltalk or Ruby[0] into this behaviour, because nil is a standard object not a magical special value (and both languages have open classes). [0] http://blog.rubyenrails.nl/articles/2008/02/29/our-daily-method-18-nilclass-method_missing http://blog.rubyenrails.nl/articles/2008/02/29/our-daily-met...

noelwelsh 11y ago

The issue is this: Things will go wrong. Some subset of things that can go wrong are things you want to do something about (e.g. file doesn't exist -- maybe prompt the user for a different file). The remainder are things you don't want to deal with (e.g. out of memory -- in most cases this is very rare so you're ok to just crash). You want to arrange your program in such a way that you must deal with the errors you want to deal with. Your code won't compile if you don't. That is what this technique brings. More here (though you probably won't understand many of the terms if you haven't used a modern FP-inspired language before): http://underscore.io/blog/posts/2015/02/23/designing-fail-fast-error-handling.html http://underscore.io/blog/posts/2015/02/23/designing-fail-fa...

wvenable 11y ago
> You want to arrange your program in such a way that you must deal with the errors you want to deal with. Which would be fine but there is no way to do that without also having being forced to deal with the infinite errors you don't want to deal with.
- kibwen 11y ago
  If you don't want to deal with an error then you unwrap it, which will terminate your program just as well as an unhandled exception would. The salient difference is that you can't accidentally unwrap something, whereas you can accidentally forget to handle an exception.
  - wvenable 11y ago
    The set of exceptions that can be handled is vanishingly small. With exceptions you should be catching exceptions very infrequently and in key places. Talking about accidentally forgetting to handle an exception at a method-call site completely missed the point. That's not how one should code or think about coding when using exceptions.
- noelwelsh 11y ago
  This is false. I use the pattern in the linked blog post everyday so that my code must deal with the errors I want to deal with and can ignore the rest.