71–80 of 93 posts
You can make methods easily return multiple values in C# with Tuples. They are very handy.
P.S. You can do this in pretty much any language. Just define pair, triplet, etc.
Everyone here seems to agree that "exceptions are for exceptional conditions". The problem is that when you get down to details, there is disagreement about what exactly is an "exceptional condition". e.g. - you are trying to open a file for reading. The file does not exist. Is this exceptional? That depends on context, but the function that opens the file, being in an independent library, is usually designed without…
a = some_dict['nonexistent_key']
a = some_dict.get('nonexistent_key', 'DEFAULT')
Earlier quoted context omitted.
Isn't that what exceptions are used for in any language?
Certainly not. In Python, for example, exceptions are used to handle exceptional conditions . Here's an example. Say I'm writing a function and I have a dictionary I need to access values from often. Now say that 85% of the time the key I need is in the dictionary, but 15% of the time it is not. I could do this: if key in my_dict: execute_operation(my_dict[key]) else: pass So that if the key is not in the dictionary…
Earlier quoted context omitted.
50 error conditions in a 20-line function doesn't really sound even remotely realistic. Probably only 5 of the 20 lines are actually calling functions that might return errors, and in most cases, we don't care what type of error is being returned. So if we're talking about 5 error-checks in 20 lines, then yes, we absolutely should write code to address them from the start . I mean, I can understand not dealing with e…
Nonsense. Is the network up? Is the connection to SQL up? Did someone just turn off the SQL machine half way through the query? Can we find the server? Are there any rows? Did the SQL compile? Do I have rights on this table? Have you just terminated me as a result of a deadlock? Did you return a Null when I was expecting a value? Did you return a float when I was expecting an int? Did my value just overflow? Did you…
Resource availability (Is the network up? Is the connection to SQL up? Can we find the server? Did I just try to access the session but some other idiot clear it?)
Incomplete response (Did someone just turn off the SQL machine half way through the query? Have you just terminated me as a result of a deadlock?)
Result semantics and types (Are there any rows? Did you return a Null when I was expecting a value? Did you return a float when I was expecting an int? Did my value just overflow? Did you just return 0 and I tried to use it in division?)
Translation to intermediate language (Did the SQL compile?)
Assumptions about remote state (Do I have rights on this table? Did I just try to call a method on an object that is in fact null?)
Smart code handles these all separately. It's crazy to try to bundle them all into one function.
Earlier quoted context omitted.
Vague value judgments ("only for exceptional conditions") are the inevitable result of a failure to reason. The semantic function of exceptions is just a way for summing additional values onto the return type of a function because it has results that are not contained within the primary type. In this way, they are a more general and better typed version of NULL (which has it's places - contrary to the modern dogma, t…
I'm really fond of the idea of Nullable types (where you have to unwrap them by checking if they're null or errors to get the value). I don't think any non-functional language other than Rust has attempted to work this into the way they work yet, but it strikes me as a powerful mechanism that could also allow for deferring error handling to the site most capable of dealing with it.
[0] http://www.scala-lang.org/api/current/index.html#scala.util.... [1] http://www.scala-lang.org/api/current/index.html#scala.util....
Everyone here seems to agree that "exceptions are for exceptional conditions". The problem is that when you get down to details, there is disagreement about what exactly is an "exceptional condition". e.g. - you are trying to open a file for reading. The file does not exist. Is this exceptional? That depends on context, but the function that opens the file, being in an independent library, is usually designed without…
Vague value judgments ("only for exceptional conditions") are the inevitable result of a failure to reason. The semantic function of exceptions is just a way for summing additional values onto the return type of a function because it has results that are not contained within the primary type. In this way, they are a more general and better typed version of NULL (which has it's places - contrary to the modern dogma, t…
Earlier quoted context omitted.
Vague value judgments ("only for exceptional conditions") are the inevitable result of a failure to reason. The semantic function of exceptions is just a way for summing additional values onto the return type of a function because it has results that are not contained within the primary type. In this way, they are a more general and better typed version of NULL (which has it's places - contrary to the modern dogma, t…
B&D? edit: Oh. http://c2.com/cgi/wiki?BondageAndDisciplineLanguage ? Makes sense.
Earlier quoted context omitted.
Vague value judgments ("only for exceptional conditions") are the inevitable result of a failure to reason. The semantic function of exceptions is just a way for summing additional values onto the return type of a function because it has results that are not contained within the primary type. In this way, they are a more general and better typed version of NULL (which has it's places - contrary to the modern dogma, t…
Overall, very good comment. My one point of disagreement is where you dismiss sum types because they clutter your program. Since sum types are the correct answer to this problem in theory, it seems to me that we shouldn't move on from that answer due to problems with implementing it in practice. Further, I think that the problem has already been solved pretty well in languages like Haskell that support type classes (…
> There's still room for improvement on working with sum types in Haskell (e.g. nested sum types can be annoying)
What I dismissed is requiring sum types to be nominal. For instance, imagine that Haskell used the Scheme/Java representation of objects (ie everything is basically a member of one sum type, discriminated on a machine word in the header). We could then do things like:
type Foo = Bar | Baz
type Foo2 = Bar | Baz
I think Rust (being not quite formed yet) could benefit from taking a stab at this, having every sum discriminator be globally unique, and every non-sum type having an associated global tag that only gets prepended when it is promoted to being an anonymous branch of a sum. The immediate use I envision is being able to create ad-hoc type hierarchies that are descriptive rather than prescriptive.
Earlier quoted context omitted.
Vague value judgments ("only for exceptional conditions") are the inevitable result of a failure to reason. The semantic function of exceptions is just a way for summing additional values onto the return type of a function because it has results that are not contained within the primary type. In this way, they are a more general and better typed version of NULL (which has it's places - contrary to the modern dogma, t…
I'm really fond of the idea of Nullable types (where you have to unwrap them by checking if they're null or errors to get the value). I don't think any non-functional language other than Rust has attempted to work this into the way they work yet, but it strikes me as a powerful mechanism that could also allow for deferring error handling to the site most capable of dealing with it.
The proper analogy would be not GOTO, but COMEFROM, no? A catch block is basically a COMEFROM. :)