CODEWITHSUNDEEP
f#
Francesco De Vittori
Francesco De Vittori

Reputation: 9290

Why does pattern matching fail on an exception in this case?

I have this simple exception hierarchy:

type FirstLevelException(msg) = inherit System.Exception (msg)
type SecondLevelException(msg, inner) = inherit System.Exception (msg, inner)
type ThirdLevelException(msg, inner) = inherit System.Exception (msg, inner)

and these three (dummy) functions:

member this.FirstFunction a =
    raise (new FirstLevelException("one"))

member this.SecondFunction a =
    try
        this.FirstFunction a
    with
    | :? FirstLevelException as ex -> raise (new SecondLevelException("two", ex))

member this.ThirdFunction a =
    try
        this.SecondFunction 25
    with
    | :? SecondLevelException as ex -> raise (new ThirdLevelException("three", ex))

It's easy to see that when you call ThirdFunction:

All good. Now I change thirdFunction in the following way:

member this.ThirdFunction a =
    25 |>
    try
        this.SecondFunction
    with
    | :? SecondLevelException as ex -> raise (new ThirdLevelException("three", ex))

things become weird: it looks like the pattern matching within ThirdFunction does not work anymore, and the SecondLevelException is propagated all the way up to the ThirdFunction caller, without being wrapped in a ThirdLevelException.

I'm sure there is a logical explanation that my C#-deformed mind can't see. Can someone please shed some light?

Upvotes: 3

Views: 597

Answers (1)

Tomas Petricek
Tomas Petricek

Reputation: 243051

The behavior you described is correct - when you write 25 |> expr, the code in expr is evaluated and the result (a function) is then called with 25 as the argument.

In your case, the result of expr is a function and the evaluation of the expression (that returns the function) is protected by your try block. However, once the function is returned, it escapes the try block and the call is made outside of the exception handler.

To move the exception handling inside this returned function, you would have to write something like this:

25 |> (fun n ->
  try 
    // You need to call the function (i.e. give it something as an argument)
    // inside the try-with block, otherwise it won't be executed here!
    this.SecondFunction n
  with 
  | :? SecondLevelException as ex -> raise (new ThirdLevelException("three", ex)))

Nobody would write this kind of code in practice, but I hope it demonstrates the problem!

BTW: I suppose this is related to your earlier SO question about handling exceptions in a pipeline. I added answer there, which may help you understand the problem. (The problem is that wrapping operations of the pipeline in try .. with won't prevent exceptions that happen inside the pipelined functions).

Upvotes: 8

Related Questions