Returning an error message when something goes wrong

[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

[Nicholas Paldino [.NET/C# MVP]]

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.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Simon" <sh856531@micro softs_free_emai l_service.com> wrote in message
news:eg******** ******@TK2MSFTN GP14.phx.gbl...

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

[Nigel Armstrong]

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

"Simon" wrote:

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

[Anders Borum]

Hello!

Good explanation!

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

Any links to these resources?!

Thanks in advance.

--
venlig hilsen / with regards
anders borum
--

[Simon]

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

[Jeff Louie]

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

result in an exception being thrown.<

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Nigel Armstrong]

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
"Simon" wrote:

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

[James Curran]

"Simon" <sh856531@micro softs_free_emai l_service.com> wrote in message
news:%2******** ********@TK2MSF TNGP14.phx.gbl. ..

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?

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