This is probably just a matter of taste, but I am curious about other's reactions. I am used to seeing catch blocks and the like written with Progress.Lang.Error, Progress.Lang.AppError, and Progress.Lang.SysError, but I encountered some code this morning which had using Progress.Lang.Error and using Progress.Lang.AppError and this allowed writing the catch blocks and throws as simply Error and AppError. In general, I am a big fan of using to keep code readable, but seeing just plain Error bothered me since it seemed obscure, but perhaps that is just because I am used to seeing it spelled out. AppError less so, but consistency would dictate one way or the other.
Thoughts?
This is probably just a matter of taste, but I am curious about other's reactions. I am used to seeing catch blocks and the like written with Progress.Lang.Error, Progress.Lang.AppError, and Progress.Lang.SysError, but I encountered some code this morning which had using Progress.Lang.Error and using Progress.Lang.AppError and this allowed writing the catch blocks and throws as simply Error and AppError. In general, I am a big fan of using to keep code readable, but seeing just plain Error bothered me since it seemed obscure, but perhaps that is just because I am used to seeing it spelled out. AppError less so, but consistency would dictate one way or the other.
Thoughts?
Flag this post as spam/abuse.
Dang, I thought I had. Let me see if I can get Jean to move it to avoid duplication.
Wait a minute ... it says OpenEdge Development is the forum. Sounds like the right place to me.
Thomas,
It's moved.
That's sort of my question. I.e., is just plain Error confusing compared to Progress.Lang.Error? AppError and SysError certainly less so, but it seems like one should be consistent.
BTW, now I'm confused since I got a message this thread was moved and I saw it on the Development forum, but now it seems like this is on RDBMS.
I think what happened with the forum switching is that I'd replied to your post of the RDBMS forum, then I moved your original post. You replied to my post and here we are again. I've moved this post too, so now we should be ok.
This is probably just a matter of taste, but I am curious about other's reactions. I am used to seeing catch blocks and the like written with Progress.Lang.Error, Progress.Lang.AppError, and Progress.Lang.SysError, but I encountered some code this morning which had using Progress.Lang.Error and using Progress.Lang.AppError and this allowed writing the catch blocks and throws as simply Error and AppError. In general, I am a big fan of using to keep code readable, but seeing just plain Error bothered me since it seemed obscure, but perhaps that is just because I am used to seeing it spelled out. AppError less so, but consistency would dictate one way or the other.
Thoughts?
Flag this post as spam/abuse.
[mention:6911e6cc8725416dba58ae08a80faffd:e9ed411860ed4f2ba0265705b8793d05] and [mention:9e4ee96fac634b8f91b580e1fb4f7e71:e9ed411860ed4f2ba0265705b8793d05] , apparently something went wrong when Peter answered back as his answer created a new thread... So I merged everything back.
And now, I'll need to create a new thread because this one is so full of off topic messages! :)
No, I'll give it a try.
Where did the new post ended? It promised to be a very rich discussion.....
Where did the new post ended? It promised to be a very rich discussion.....
Flag this post as spam/abuse.
No, I think it is all here, just confused by the moving messages.
So, to bring things back, I get Peter's point that using allows one to use a simple name but that this can be undesirable if the simple name is potentially ambiguous without the qualification, e.g., Progress.Lang.Object and System.Object where seeing just Object in the code would require referring back to the top of the problem to know which was which.
So, my question is whether they think Error for Progress.Lang.Error is ambiguous in this way. AppError and SysError don't seem so, but stylistically I would prefer to treat them all the same.
What I learned from the error handling handbooks and webcast, i sthat Progress.Lang.Error is just a higher level object, and I should instanteate AppError and SysError, don't I?.
Even for the standards point of view, it calls for better grouping for the source of error, don't you think?
Progress.Lang.Error is an interface, not a higher level object.
And for the direct question of Dr. Thom, I guess that the shortened form of error naming means much more presumptions by original coder about how could a maintainer coder to see the actual code...(sorry my spagethi).
Anway, I say that more structured applying of standards is more solid code, don't you agree?
sorry, I meant higher in the hierarchy, from the point of view of apperror, and syserror, and yes... absolutelly, an interfase. that's why you recomend to instanteate the app & syserror class, and not directly from .Error... Am I right?
Re the interface, you cannot instantiate an interface. So yes, of course the actual class will be some other type like AppError or SysError.
Re the original question, seems to me you could argue about this with any usage of the USING statement. But I'll let you folk argue about the merits or demerits of that.
What I learned from the error handling handbooks and webcast, i sthat Progress.Lang.Error is just a higher level object, and I should instanteate AppError and SysError, don't I?.
Even for the standards point of view, it calls for better grouping for the source of error, don't you think?
Flag this post as spam/abuse.
Hi Thomas, Mike, Laura, Peter and all,
For unexpected exceptions that can be either low level ABL errors (Progress.Lang.ProError = plp) or errors of my own App (Progress.Lang.AppError = pla) I like to use the generic interface with a single CATCH Progress.Lang.Error (ple) block, then I use a little utility getErrorMessages() method in a static class (see below). The reason why I do that is I consider I extend the language with my App. I may use my own App Error objects as well when appropriate, with some extra catch block(s) prior to the last generic ple, but so far, it happens rather rarely
I should not have a problem to handle a SysError with that, should I?
/Sébastien L.
METHOD PUBLIC STATIC CHARACTER getErrorMessages(ple AS Progress.Lang.Error):
DEFINE VARIABLE iMaxMsg AS INTEGER NO-UNDO.
DEFINE VARIABLE iMsg AS INTEGER NO-UNDO.
DEFINE VARIABLE cMessageDetails AS CHARACTER NO-UNDO.
DEFINE VARIABLE pla AS Progress.Lang.AppError NO-UNDO.
pla = CAST(ple, Progress.Lang.AppError) NO-ERROR.
iMaxMsg = ple:NumMessages.
DO iMsg = 1 TO iMaxMsg:
cMessageDetails = cMessageDetails + "~n" + ple:GetMessage(iMsg).
END.
IF VALID-OBJECT(pla) THEN cMessageDetails = cMessageDetails + "~n" + pla:ReturnValue.
RETURN SUBSTRING(cMessageDetails, 2).
END METHOD.
Hi Thomas, Mike, Laura, Peter and all,
For unexpected exceptions that can be either low level ABL errors (Progress.Lang.ProError = plp) or errors of my own App (Progress.Lang.AppError = pla) I like to use the generic interface with a single CATCH Progress.Lang.Error (ple) block, then I use a little utility getErrorMessages() method in a static class (see below). The reason why I do that is I consider I extend the language with my App. I may use my own App Error objects as well when appropriate, with some extra catch block(s) prior to the last generic ple, but so far, it happens rather rarely
I should not have a problem to handle a SysError with that, should I?
/Sébastien L.
METHOD PUBLIC STATIC CHARACTER getErrorMessages(ple AS Progress.Lang.Error):
DEFINE VARIABLE iMaxMsg AS INTEGER NO-UNDO.
DEFINE VARIABLE iMsg AS INTEGER NO-UNDO.
DEFINE VARIABLE cMessageDetails AS CHARACTER NO-UNDO.
DEFINE VARIABLE pla AS Progress.Lang.AppError NO-UNDO.
pla = CAST(ple, Progress.Lang.AppError) NO-ERROR.
iMaxMsg = ple:NumMessages.
DO iMsg = 1 TO iMaxMsg:
cMessageDetails = cMessageDetails + "~n" + ple:GetMessage(iMsg).
END.
IF VALID-OBJECT(pla) THEN cMessageDetails = cMessageDetails + "~n" + pla:ReturnValue.
RETURN SUBSTRING(cMessageDetails, 2).
END METHOD.
Flag this post as spam/abuse.
The issue is not which of these to use ... they each have their purpose*. The issue is whether to use fully qualified names when using them or to use a using statement and an unqualified name.
*SysError for system issues, AppError for application issues, and Error as a catchall.
I am currently using all three. AppError to catch things I throw and simply put a message in the log. SysError also logs the call stack so I know where it happened. And, just plain Error is catching things from Proparse that are not caught by the other two.
Yes, the original question was one of style ... most of the subsequent posts haven't been. :)
Weren't you the one who suggested I do what I am now doing for the Proparse errors?
Further advice welcome. The catch of Error has allowed us to find some constructs which were not supported including TABLE-SCAN and the use of LIKE in method parameters (yuck), but we are still getting a bunch of Prorefactor.Exception and java.Lang.NullPointerException which seem to be happening in the original parse, i.e., prior to the point where I can track line numbers. Sometimes we get a call stack; sometimes we don't; but even when we do it isn't pointing at anything clear. John has a new version that should cover the things we have identified, but it is hard for him to fix something when we don't know what is wrong.
Further advice welcome. The catch of Error has allowed us to find some constructs which were not supported including TABLE-SCAN and the use of LIKE in method parameters (yuck), but we are still getting a bunch of Prorefactor.Exception and java.Lang.NullPointerException which seem to be happening in the original parse, i.e., prior to the point where I can track line numbers. Sometimes we get a call stack; sometimes we don't; but even when we do it isn't pointing at anything clear. John has a new version that should cover the things we have identified, but it is hard for him to fix something when we don't know what is wrong.
Flag this post as spam/abuse.
Well, I started the thread on a question of style, whether people thought qualifying or not of error classes was preferable.
Now, we seem to be talking about error handling for .NET.
Mike, OK, so I could create an catch block for those two errors. I presume this is just catch blah as class name. But, can I then do anything different than with the catch on Error? The problem is getting no information.
a) They need to convince someone to add to the syntax of proparse
b) They need to convince someone to fix a bug deep doen in the guts of proparse
Well, I started the thread on a question of style, whether people thought qualifying or not of error classes was preferable.
Now, we seem to be talking about error handling for .NET.
Mike, OK, so I could create an catch block for those two errors. I presume this is just catch blah as class name. But, can I then do anything different than with the catch on Error? The problem is getting no information.
Flag this post as spam/abuse.
John has added to the syntax for the things we know about. The problem is that we are getting these errors that don't provide a line number or a token, so we don't know what to ask to be added. Since users of the tool are likely to come to me for help anyway, giving a nicer error message doesn't have a terribly high value ... window dressing, rather than any actual help in solving the problem.
John has added to the syntax for the things we know about. The problem is that we are getting these errors that don't provide a line number or a token, so we don't know what to ask to be added. Since users of the tool are likely to come to me for help anyway, giving a nicer error message doesn't have a terribly high value ... window dressing, rather than any actual help in solving the problem.
Flag this post as spam/abuse.
Well, it doesn't have anything to do with the original question ... only Peter has commented on that, really.
It does have to do with error handling if there is anything I could be doing differently that would give me more information about what is happening with Proparse.
So, I should start one?