Simple Error Handling

I have to apologize that after all this error handling banter I really don't know what the issue is.

As someone (Peter Judge?) had answered in the prior conversation (that I can't see here) you should make sure there is an error message in your AppErrors by passing 2 parameters to the constructor (message and #) or using the AddMessage method.  Then you can always get the message with GetMessage. Why would you care about ReturnValue?  That is only really there for backward compatibility with non-structured error handling.  

The Error interface will work for all error types, including .NET exceptions.  You can have a single catch block or more than one.  If you only have one you can always test the type of the actual error object you got if you need to get extra information from that specific type - like ReturnValue if you still want to use that.  You can have both a ReturnValue and an error message in the same AppError.  

So what's the question/problem?

Are you saying that if I include an error number in addition to the message when throwing an AppError, that it will show up in GetMessages?  I thought I tried that and did *not* get anything.

Correct. There are two different AppError constructors, one that just takes a message (which sets ReturnValue) and the other that takes a message and a # (don't remember in which order).  This sets an error message and a message #.  And regardless of which constructor you use, you can always add a message or set a ReturnValue by using the other methods and properties of AppError.  

To answer the original question:

ProError is the super class for AppError and SysError, but not for other errors, e.g. .Net errors.

But all errors implements the Error interface.

So you can catch the AppError and use its ReturnValue and/or any messages it contains, followed by catching the Error interface to catch anything else that is left.

Alternatively you can catch the Error interface only. If it has no messages, you can test if it is an AppError and if so, cast it and check for a ReturnValue.

I do not quite comprehend why the two AppError contructors cause you to always end up without a message somewhere, as it always complicates things and leads to unnatural code, e.g. "NEW AppError('My messages', any0meaningless-integer)" just to get the "new" structured error handling to work.

For compatibility with traditional errors, I would expect that the ReturnValue property's getter should simply map to GetMessage(1) and that it would either be a) ReadOnly, or b) have a setter that either insert the message in the first position or clear all other messages and insert only the supplied message. This would also enabled us to use structured error handling while still using the more productive, simpler to read, easy to type, RETURN ERROR "Some message" to raise the AppError, which would be closer to the life long philosophy of PSC to produce a 4GL where the programmer focus on what, not how, something happens.

Right, Laura, it doesn't have to be meaningless, but unless one commits to a systematic program of creating numbers, it will be meaningless and I find that disturbing because it is deceptive.  I would have been much happier had AppError always set a message and ReturnValue produced the same result as GetMessage(1).

But, Simon's discussion has clarified things for me.  The context in which the question arose is a routine using Proparse so appropriate sprinkling of Error is appropriate to catch anything Proparse does.  Now that I have found an occasion to also throw an AppError, the simple thing is to add a catch block for that and avoid testing and casting and branching.  

We use the error number extensively as we have an error message table that allows our end users to customize the error.

Exactly....we deal with retailers. You sometimes have to hit a cashier over the head to get them to understand.

[quote user="Laura Stern"]

Evan, what would prevent returning the RETURN-VALUE for an AppError in response to Get-Messages(1) instead of the latter returning nothing?