Handling error on service side

Question

We have WCF service implemented in our project and it contains very complicated error handling. Pretty much all methods start with Try\catch block which are catching generic exception. Mean catch all. We would like to rework this service and I was trying
to find some information's about error handling for WCF services. However information's which I found are very confusing. Let's say that we have following OperationContract implementation :
public IEnumerable<string> GetInstanceUids(string seriesInstanceUid)
if (string.IsNullOrEmpty(seriesInstanceUid))
throw new ArgumentException("Given serieInstanceUid can't be null or empty string;");
return myIsaDataProvider.QueryDicomInstances(seriesInstanceUid).ToList();
Now what I found on internet is following statement (or similar). In instances where an unhandled non-FaultException is thrown, one of the following may happen based on the instance management settings of your service. For sessionful services: The session
is terminated, the service instance is disposed and the channel will be in the faulted state, thus the proxy cannot be reused.
This doesn't make much sense to me as base on the MSDN all such exception are automatically converted to FaultException. So in which case code call cal lead to non-FaultException exception type ? Also from my synthetic test (debug environment) I can call
that method many times with null argument and service is still in operational state (it will not refuse to make additional calls). On client side I'm just handling FaultException which will log message.
So main question is. Are code as in our contract going to fault service as such so no further calls will be possible in service instance ? Which mean that all our service methods need to be wrapped in try\catch blocks and swallow all exceptions. Which is
not optimal from performance reasons.

Answer 1

thnx for your response, but I don't see how your reply can be marked as answer if it's not answering original question ! Question was if service will be in faulty state.
It wouldn't be in a faulted state if you had learned how to develop a WCF service properly, which would have involved request/response objects and catching the exception properly and returned the response object.  Something is causing the service
to crash, and you don't know what it is.
https://msdn.microsoft.com/en-us/library/ff699490.aspx
If you have ever seen or used the Web Service factory that builds the WCF Web service and uses Request/Response objects, you would appreciate the Request/Response objects in play. And there wouldn't have been some kind of generic exceptions where WCF
swallowed the real exception on tossed you back the catch 22 exceptions.   It should have never made it to a fault exception.