0

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?

  • I don't know the DLL limitations. But I think that a unique type of exception with the error code will be a good approach – Dherik Aug 2 '18 at 17:51
1

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.

2

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.

  • Well the file extension ends up being .dll, but yeah, I'm talking about .NET assemblies. So in our case we're calling a third party REST API, if the call fails and returns an error message, say because we didn't make the call with the right parameters (end date before start date or something), do you see that being an exception or returning false? – John Aug 1 '18 at 13:01
  • @John - IMHO, that should throw an exception. It should be just like you've statically linked your code. The fact that its in an assembly doesn't matter. The assembly mechanism allows you to share types across assemblies (and the exceptions in question probably come from some third assembly anyhow, maybe the HttpClient one, or System, depending on the exception). – Lewis Pringle Aug 1 '18 at 14:10
1

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.

  • So in our case we're calling a third party REST API, if the call fails and returns an error message, say because we didn't make the call with the right parameters (end date before start date or something), do you see that being an exception or returning false? – John Aug 1 '18 at 13:00
  • If it's an issue on our or server side which require fixing (it's a bug) or we need to additionally validate parameters or something else which should be changed because it's not normal then I'd rather stick to exception, in case this is done by design(in this specific case I don't see any reason behind) then we could consider using result code instead. – Sergey Prosin Aug 1 '18 at 13:21
  • Ok, maybe a better example then: A login method. The end user enters their username / password. Our client-side program makes the login request to the third party REST API and that API says the login failed. Our login method wrapper is in the DLL, since it will be shared across other projects. Should it return false and put the error message on an instance variable, or should it throw an exception? – John Aug 1 '18 at 13:28
  • In this context I see the following: api can't be used without being authenticated, so it's definitely should be an exception. – Sergey Prosin Aug 1 '18 at 13:33
  • In addition to that there might be a lot of reasons why it has happened, so you need to get the app know about a reason by providing error details. – Sergey Prosin Aug 1 '18 at 13:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.