From what I understand, exceptions are very slow and are not useful for returning error information repeatedly in a loop, but most class methods in Microsoft’s APIs make great use of exceptions, to the point where handling every possible scenario gets annoying, because it becomes necessary to write a lot of try/catch blocks. In my opinion, try/catch blocks are not very attractive and have performance issues. It would be better for me if in all classes I define myself, I could somehow avoid forcing the caller to handle exceptions, especially when the caller code is written by me. There has to be some strategy that is consistent with the elegance of C#, that does not require me to use exceptions. I need a strategy that will be used throughout all my projects consistently. But I am not sure exactly what strategy to use.

Since functions can only return objects/values of a specific type, would it make sense to return both success and failure information? I would think that error objects would be of a different type than objects resulting from success, so they could not both be returned. Maybe I should have a result object, wherein I can specify a class type for errors and a class type for the result. But would this be at all elegant? Or should I use reference parameters? In your opinion, what is the best way to handle errors without having to deal with exceptions? I am sure that finding an alternative will not only make coding less tedious for me, but also improve performance in loops.