Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monads in C# (Part 2): Result

alexyorke.github.io

Post reply on HN
Print view View original

71–75 of 75 posts

Re: Monads in C# (Part 2): Result

#71

Post by wvenable »

naasking wrote: post #69
wvenable wrote: post #68

Earlier quoted context omitted.

You should leak implementation details on exceptions -- if an operation fails because of a network timeout or file access issue, that's useful information. Most exceptions cannot be meaningfully caught anyway so let me log with a good stack trace and be done with it.

The inner, wrapped exception is logged. Leaking exception details can also leak privileged information, and if you're not careful this can leak information to attackers too. More information is not necessarily better.

If your error logging is leaking privileged information to attackers that's a completely different problem from what you should do in code when throwing exceptions.

Wrapping exceptions to remove information is mostly a pointless exercise. You should be doing it only to add additional context.

Re: Monads in C# (Part 2): Result

#72

Post by FrustratedMonky »

louthy wrote: post #48
debugnik wrote: post #43

Earlier quoted context omitted.

That will allocate for any constructed Either though. F#'s Result and ValueOption are value-types (structs), and value-type variants recently added support for sharing fields between variants when the name and type match.

Yes, that's the limitation until the value-type DUs arrive in C# 15. In previous versions of language-ext, I defined Either as a struct with bespoke Match methods to pattern-match. But once pattern-matching appeared in C# proper, it didn't make sense to keep the struct type.

Sounds like C# 15 will be it then? Everything unique about F# will be incorporated.

I guess a lot of how F# structures projects, like file order, or not using nulls, can be done by programming rigor?

Re: Monads in C# (Part 2): Result

#73

Post by naasking »

wvenable wrote: post #71
naasking wrote: post #69

Earlier quoted context omitted.

The inner, wrapped exception is logged. Leaking exception details can also leak privileged information, and if you're not careful this can leak information to attackers too. More information is not necessarily better.

If your error logging is leaking privileged information to attackers that's a completely different problem from what you should do in code when throwing exceptions. Wrapping exceptions to remove information is mostly a pointless exercise. You should be doing it only to add additional context.

It's not a different problem, my whole point was that letting exceptions bubble is not a universally acceptable policy. Sometimes you want to bubble, sometimes you want to wrap, and sometimes you want to wrap with information hiding to avoid leaking information.

Re: Monads in C# (Part 2): Result

#74

Post by wvenable »

naasking wrote: post #73
wvenable wrote: post #71

Earlier quoted context omitted.

If your error logging is leaking privileged information to attackers that's a completely different problem from what you should do in code when throwing exceptions. Wrapping exceptions to remove information is mostly a pointless exercise. You should be doing it only to add additional context.

It's not a different problem, my whole point was that letting exceptions bubble is not a universally acceptable policy. Sometimes you want to bubble, sometimes you want to wrap, and sometimes you want to wrap with information hiding to avoid leaking information.

> my whole point was that letting exceptions bubble is not a universally acceptable policy.

It should be. It should bubble to whatever boundary you have (web API, event loop, etc). At that boundary, if it's not supposed to leak information then don't. Do whatever sanitation you need at one point only. Good use of exceptions should have as few "catch" blocks as possible.

Re: Monads in C# (Part 2): Result

#75

Post by debugnik »

louthy wrote: post #48
debugnik wrote: post #43

Earlier quoted context omitted.

That will allocate for any constructed Either though. F#'s Result and ValueOption are value-types (structs), and value-type variants recently added support for sharing fields between variants when the name and type match.

Yes, that's the limitation until the value-type DUs arrive in C# 15. In previous versions of language-ext, I defined Either as a struct with bespoke Match methods to pattern-match. But once pattern-matching appeared in C# proper, it didn't make sense to keep the struct type.

Aren't the upcoming C# "value-type" DUs just a wrapper over an object reference? Value-type cases will be boxed AFAIK.
Post reply on HN