Should I catch and reconstruct the exception in this case?

Question

I am developing in the user interface layer of the application, and after I make the request, an exception is thrown at the business level (or lower). The exception is as follows

"Fix System.Exception: data not returned ..."

Which of its obvious ones did someone simple:

if (...Rows.Count < 1) throw new Exception("No Data Returned"); 

Now on my playground, I should try to clear this, trying to restore it as a custom exception, which I can handle just like this:

 try { var myBusinessObject = MyBusinessMethod(); } catch (Exception ex) { if (ex.Message == "No Data Returned") { throw new NoDataException(ex.Message); } else { throw; } } 

Or is there a more graceful way to handle them.

Please note: I do not have the ability to modify code outside of the user interface level, and I expect that you will often come across this particular exception.

Thanks in advance!

Answer 1

This is a bit subjective, but I'd rather live with the ugliness of catch (Exception) handling in my code than worry about what happens if someone changes the error message to something other than No Data Returned .

Answer 2

I really think it depends on what this exception means in the context of your call. For example, if you request to download a client by name or identifier, an exception may simply be passed to your user with the "client not found" dialog. If, on the other hand, you are trying to load something critical that you think should be there, and you get this exception, you need to do something else.

The bottom line is that it really depends on the nature and severity of the problem and what your client expects from the user interface.

Answer 3

If you cannot control or change the code at lower levels, you can only inform the user and invite him to repeat the operation or take other actions. You do not need to display an exception message for the user (if this is not required). Instead, if possible, it would be useful to send a message to the business layer with information about the method being called and the arguments passed.

Answer 4

The answer is very specific and depends on your requirements and the usability of your application.

In particular, at the user interface level, the answer largely depends on what will make the application more usable and what system / system you have for error handling.

Typically, errors that extend so far will fall into two broad categories:

• Issues that the user should be aware of and / or that significantly affect usability. Typically, these are problems that you want to enter user input into before deciding what action to take next (i.e., if the username is not found at logon, or the data you are trying to display is not available). Instead of throwing a new exception, more often than not, you probably report an error that matches your system.

• Questions that the user should not know about, which are not related to the proper functioning of the systems, or which are relevant only to system administrators, etc. These problems are usually better handled by throwing an exception, as you will usually have a top-level layer that writes exceptions to sysadmins / etc .. for registration