My development environment specifically is .NET and I'm writing a DLL to be compiled and referenced in other .NET programs we'll be writing going forward.
My question is: In that DLL, what is the best practice for error handling? If you have a function doSomething(value) and it fails, do you throw an exception? Or do you return a boolean indicating success/failure and have an instance variable that you check for the error message?
In old times, before the invention of exceptions, the most painful thing about coding was to stop your program from blindly continuing after some API call failed. You had to check every single function-call result for being NULL, -1 or whatever the designer chose as his signal of failure, and then to return from your function with your failure-signalling value. Things like this (e.g. in C):
FILE *fp = fopen(...);
if (fp == NULL) {
return -1;
}
One productive line of code, three ugly, boilerplate ones.
When using exceptions, this comes for free. So, wherever technically possible, use exceptions to signal failures (but not everything is a failure, e.g. when searching for a substring in a string, not finding it shouldn't throw as that's normal). Without exceptions, you're forcing your colleagues into this ugly coding style.
And put information about the failure into the exception object, if it isn't automatically included, e.g. the file name when trying to open a file, so the sysadmin reading the log knows where to search for the problem.
When consuming REST services, I'd recommend to wrap failure codes in exceptions if your REST library doesn't already do that.
Your choice of words - 'DLL' instead of 'assembly' - gives me pause.
Generally, the best way to handle errors is via exceptions.
Possibly the only good 'exception' ;-) to that rule would be in the case of DLLs, where you can get into trouble throwing exceptions across DLL boundaries.
However, one of the places this works BEST, is with .net. .Net comes as a bunch of assemblies, and so throwing across assemblies is extremely common.
So - in short - since you say you are using .net (and this implies I believe that your DLLs are assemblies) - you should have no trouble throwing and catching exceptions, so this would be the best practice.
Generally speaking, some of best practices documents could be used as a basis, for example, https://docs.microsoft.com/en-us/dotnet/standard/exceptions/best-practices-for-exceptions. Being specific, design classes so exceptions could be avoided (meaning don't plan using exception handling as part of normal flow) because it affects performance significantly (need to collect stack trace etc.) but in case there is an exceptional situation, an exception should be thrown instead of returning booleans, defaults, etc. If you expect throwing exception to be part of the normal flow (a bright example is when you parse a string into integer you expect that there might be frequent errors) you can provide specific Try-methods (such as TryParseInt) thinking of the system performance.
