5

In .NET, it is idiomatic to suffix exception types with Exception. But most, if not all, sources I have seen for custom exception types in F# don't follow this idiom.

Most seem to use the suffix Error.

From F# For Fun and Profit

exception MyFSharpError1 of string
exception MyFSharpError2 of string * int

From Microsoft Documentation*

exception MyError of string

The book 'Expert F# 3.0', co-authored by Don Syme, has an example that doesn't even seem to follow any idiom:

exception BlockedURL of string

Why don't custom exceptions in F# follow the standard idioms for .NET? Is it because of the OCaml heritage?

* Link is to Google cache, as I cannot connect to MS at the time of writing.

4

I think you're too quick to generalize based on just a few data points. There is some diversity there, but on the whole you're still more likely to see *Exception than anything else, in my experience at least.

As for why there is more variation out there, I think there are a couple of different factors at play:

  • F# is a .NET language and uses the same standard libraries which follow the *Exception convention. Also, a great number of users comes to F# from C#, and they're likely to use what has worked for them so far. Look at github results, there's plenty of *Exceptions there (admittedly, some *Errors as well).
  • You seem to be correct about OCaml heritage - again, going by github results, it's a widespread practice to name exceptions without any suffixes. The few *Exceptions I saw came from .fs files classified as OCaml.
  • C# has its golden standard code guideline that everyone seems to follow unanimously; I don't think F# had anything comparable from the start. Now there's F# Component Design Guidelines document from FSF, and it actually advices to follow the .NET *Exception style.
  • Previous point is further aggravated by the fact that compared to C#, there's very little tooling support for F#. There's no Resharper/StyleCop/FxCop for F# to enforce a code style for you (heck, there's not even a "Rename" out of the box in VS!).
  • The guidelines you mention for C# are not actually C#-specific at all, they apply to all .Net languages (including F#). – svick Jul 7 '14 at 13:24
  • They are pretty C#/VB.NET-centric even if it doesn't say so on the tin. I assure you that following some of them in F# would lead to hilarious results. And .NET hosts many other languages where they'd be out of place as well. – scrwtp Jul 7 '14 at 18:31
  • I do agree that keeping to those guidelines on a public interface level would be a nice gesture if you're writing an F# component intended to be consumed by clients written in other languages (read: C#). This does include naming exceptions your code might throw accordingly. – scrwtp Jul 7 '14 at 18:38
  • Those guidelines apply only to the public interface level. They're not meant to tell you how to write your implementation (for example, they explicitly don't say how to name private fields). – svick Jul 7 '14 at 18:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.