0

In Java, calls to functions that can throw Exceptions need to anticipate them with either a try-catch or by adding a throws Exception to their function signature.

My main use for them is in my top-calling code, where I only put try-catches in sections that explicitly throw Exceptions.

However, because C# does not have checked exceptions, the only way I can think of anticipating Exceptions is to surround all sections of my top-calling code with try-catches. I personally do not like this approach for the following reasons:

  1. It can lead to very messy code, putting try-catches where they are not needed.

  2. I might miss a section that needs a try-catch.

How do I properly anticipate Exceptions in my top-calling code in C#?

Floating Sunfish
  • 4,920
  • 5
  • 29
  • 48
  • Why do you think you have or should consume all exception at some point? I would say that's a bad practise because exceptions are there for a reason. – user743414 May 27 '19 at 08:21
  • @user743414 Don't exceptions need to be handled in C# otherwise your app will crash? I only handle Exceptions by logging them. – Floating Sunfish May 27 '19 at 08:22
  • Yes it will and should crash because something is wrong with your code when an exception is thrown. So it would be better to fix the issue than to consume it. You should only catch exception when you can restore some kind of working state in your application, if not I think it's better to crash than to work with some invalid state in your program. – user743414 May 27 '19 at 08:24
  • @user743414 Indeed, I am only catching Exceptions because I know they might happen beforehand and that I need to keep going after they happen (e.g. Network errors, or a custom Exception that I wrote to signal me that I need to take a specific course of action before proceeding). – Floating Sunfish May 27 '19 at 08:26
  • Do you have an example for an exception which is raised eventually? – user743414 May 27 '19 at 08:30
  • @user743414 Usually some run-of-the-mill ones, but let's stick with a basic Exception for this example. Let's say I had a function that returns records from the DB and also raises an Exception when it can't find any records. I am using the Exception as a handy way for me to know that the function was not able to finish its job the normal way, and now my calling code needs to return an error message (e.g. "No records match the given criteria.") instead of a records list. Stuff like that. – Floating Sunfish May 27 '19 at 08:34
  • In such a case I wouldn't throw an exception, because the method works. It just returned no results. I would return a List res = new List() with zero entries and check that. :) – user743414 May 27 '19 at 08:39
  • @user743414 Indeed, that is another way to handle it, but my coding style is a bit different. :P I prefer to raise Exceptions when non-standard things happen. In any case, many thanks for asking! – Floating Sunfish May 27 '19 at 08:40
  • 1
    What you could do is raise specific exceptions for example "RepositoryNoResultsException" or "ServiceXYZException" and catch these specific exceptions on a higher level. But you shouldn't raise generic System.Exception as a general purpose exception to indicate that a method does not return someting. Because than you'll have the issue with catched exception you don't want to catch. – user743414 May 27 '19 at 09:05
  • @user743414 The reason I raise generic System.Exception is because I only want to log the error and show it to the User. If the error was "No records found," the user can see it and do something else. If the error was "some_technical_exception" then the user can report it to customer service or something, where we can add new code to handle such scenarios much more gracefully the next time they occur. Logging Exceptions and printing their messages is enough for our purposes though. – Floating Sunfish May 27 '19 at 09:09
  • This is a very common misconception, one that when pursued results in programs that misbehave undiagnosably when an exception is handled. The essential burden of a catch-clause is that it must restore program state, as though the failing code was never called. When you write try/catch-em-all code then you can rarely do this correctly, you have but a vague idea what caused the exception and how to restore state. Proper guidance is to keep exceptions as exceptional, only write a try/catch when you observed a *specific* exception while testing and have figured out how to deal with it. – Hans Passant May 27 '19 at 11:27
  • This does mean that you must never catch System.Exception. Only ever throw your own Exception-derived class when the intention is to handle it. And that "No records found" is not exceptional, avoid using exceptions for flow control. – Hans Passant May 27 '19 at 11:29

0 Answers0