Returning an error message when something goes wrong

  • Thread starter Thread starter Simon
  • Start date Start date
S

Simon

Hi everyone,

I'm wondering what you're supposed to do when you call a method that is
required to perform some action but that action subsequently fails. More
specifically, how do you get a custom message back so that you can provide
some useful information to the application user?

It seems we dont have much room for manouever.

Example:


I might have a method called load file which is supposed to return a file
object. Inside this method a problem is detected and the file object can't
be loaded correctly.

What do I do?

Do I return an empty file object and just accept the fact that I cant return
helpful info to the user?
Do I throw an exception even though the file not being loaded isnt really an
exceptional occurence?
Or is there some other approach i can use.

The only way i can see to return context based error messages is to throw an
exception. However, I don't see how you can reconcile the use of exceptions
in non-exceptional circumstances given the general wisdom that says you
should only throw exceptions when something truly unexpected has happened.

Thanks in advance for any advice you can offer.

Kindest Regards

Simon
 
Simon,

You could always return an error code, an integer (or value from an
enumeration) indicating what the status is. This would allow you to
indicate a good number of situations, which should suit your needs.

Hope this helps.
 
Hi Simon

Another perspective - you can consider that an Exception should be raised
when the calling code has violated the implicit assumptions of your class.

Imagine that you have an argument on a method which allows you to set the
age of a person in years. For efficiency, you choose to use an int to
represent that value. An implicit assumption of your class which isn't
covered by the datatype int, is that the age of a person in years should have
a maximum value of say 130.

If a client of your class calls the method passing through the value 250,
then you should raise an Exception - the implicit assumption of your class
has been violated...the exception should be raised with an appropriate
message so that the developer who is using your class can be told why the
method call wasn't appropriate.

Note that in this case, it's not a circumstance that may happen infrequently
(which is how many people think of exceptions), but it's when the data
supplied does not conform to the internal assumptions that your class makes.

I think this is Richter's view of exceptions. Other views??

Nigel Armstrong
 
Thanks guys. Thats all good stuff.

Additional question:

How do you manage the proliferation of exception throwing classes if you use
this approach.

Seems to me that all classes have internal assumptions that might result in
an exception being thrown. Surrounding everything in a tcf block isn't
really a sensible option so can anyone suggest a decent approach to making
sure that you catch exceptions without them bringing the application down?

Thanks again all

Simon
 
Simon...

I argue that the decision to return an error code or throw an exception
in a method that opens a file is dependent on the explicitly stated
pre-conditions of the method. If a pre-condition of a method that opens
a file is that the file must exist, then the method should throw an
exception if the file does not exist. Alternatively, if there is no
stated pre-condition that the file must exist then the method should
return an "error code" on failure to find a file. For instance, the
method might return false on failure to find a file.

Regards,
Jeff
Seems to me that all classes have internal assumptions that might
Click to expand...
result in an exception being thrown.<
 
Hi Simon

This is a problem that thankfully we don't have to deal with in the same way
that our J*** friends do. In Java, the majority of exceptions are checked
exceptions. So when you try to open a file, you have to write a try catch
block to handle the IO Exception that might occur, or modify the signature of
the method to state that it may throw an IO Exception. In .NET, if you choose
not to write a try catch, then the Exception propagates up the call stack
until the app exits, which means that you have the chance to write a central
Exception handler if you so choose...it's a situation that Java has only just
addressed, and for those of us who have / are using both environments, it's
clear that the .NET way of doing things is better!!

It also depends on what sort of app you are writing - Windows Forms and
ASP.NET applications have different ways of writing the central handler.

HTH

Nigel Armstrong
 
Seems to me that all classes have internal assumptions that might result in
an exception being thrown. Surrounding everything in a tcf block isn't
really a sensible option so can anyone suggest a decent approach to making
sure that you catch exceptions without them bringing the application down?
Click to expand...

Simple.... Catch the exceptions at the level where you can deal with
them. For the most part, conditions that throw an exception would prevent
the application from continuing anyway. So, most of the time, you just want
to catch all exceptions at the highest level, and output a pretty messages
before shutting down. (The exception itself should contain sufficient
information on what failed & why)

If a exception is a condition that you can recover from (and if so,
reconsider using an exception), catch it at the level you can deal with it &
retry.

--
Truth,
James Curran
[erstwhile VC++ MVP]
Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
 
Back
Top