3 ms·
I'm sorry, I ignored the second part of your question. I was responding to: > What is an example of exception that happens many times per second? I made a di
by steego 8y ago
I'm sorry, I ignored the second part of your question. I was responding to:
> What is an example of exception that happens many times per second?
I made a distinction between exceptions and errors because exceptions are a specific mechanism for propagating errors. I wasn't trying to be pedantic, I was trying to point out that the answer to your first question is more obvious if you subsitute out the word exception for error.
The answer is simply: Because you're probably the one generating the errors and you're going to generate a lot of them.
With regards to the second question:
> And where it could not be easily avoided to step on the error path at all?
I'm not sure how to interpret this question, but I'll throw out an answer anyway. You don't need to take a Railway Oriented Approach. There are other ways. Your reply was an example.
For a streaming scenario, applying a function with the signature ('a -> Result<'b,'e>) to a Stream.map is pretty trivial. It may not be the most performant or scalable, but it's easy to do and easy to reason about. However, one could also easily create two streams as you suggested with a partition type function with the signature: (Stream<'a> -> ('a -> Result<'b,'e>) -> (Stream<'b> * Stream<'e>)
You're free to use the Result<> type as much or as little as it makes sense. How one should best solve the problem depends on the scope of the problem and what you need to do downstream, right?
- jstimpfle 8y ago> I wasn't trying to be pedantic, I was trying to point out... I agree! > but it's easy to do and easy to reason about I agree it's an obvious/intuitive approach to take, just like OOP. However, from a computational and software maintainability standpoint, I think it rarely pays out. > How one should best solve the problem depends on the scope of the problem and what you need to do downstream That's right, however ADTs are very rarely occurring naturally in what I do (I've dabbled in quite a few areas). I've found them to occur naturally in parsers (because languages have forks in their syntaxes), but even there I've had great gains by avoiding ASTs altogether, and making multiple streams, supported by a ADT stream of simple data that does not contain real data but only "joins" the other ones (it contains only a type-flag and a pointer into one of the other streams). I think ADTs are the right choice whenever the ordering between a set of things with heterogeneous types is very important. If that's not the case, code can be vastly simplified by sorting the data by their types and processing them as separate bins - separately and independently.