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:
- firstFunction raises a FirstLevelException
- secondFunction catches it, wraps it into a SecondLevelException and throws it
- thirdFunction catches it, wraps it into a ThirdLevelException and throws it
- the caller can catch a ThirdLevelException.
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?
The behavior you described is correct – when you write
25 |> expr, the code inexpris evaluated and the result (a function) is then called with25as the argument.In your case, the result of
expris a function and the evaluation of the expression (that returns the function) is protected by yourtryblock. However, once the function is returned, it escapes thetryblock 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:
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 .. withwon’t prevent exceptions that happen inside the pipelined functions).