M
Mike Fechner
Guest
Must say I share Peters preference here. Plus the individual catch blocks on AppError and SysError would allow you to on purpose not catch Exceptions and SoapErrors. Using a Single catch for Error with the CASE you will have to re-throw error you can't handle there. This is even more true when you start adding custom error types (Childs or grand Childs or grand grand Childs of AppError) and need different handling in different locations for custom errors like NotAuthorizedException vs. assertException vs. NotSupportedOnMondayException. Von meinem Windows Phone gesendet Von: Peter Judge Gesendet: 21.05.2015 02:52 An: TU.OE.Development@community.progress.com Betreff: RE: [Technical Users - OE Development] Simple Error Handling RE: Simple Error Handling Reply by Peter Judge It's a preference 
Both work equally well. Catch eAE as AppError: pcError = eAE:returnVAlue. End catch. Catch eSE as SysError: pcError = {fnarg fnRtbErrorHandlerObject eSE}. End catch. Catch eE as Error: Do iLoop = 1 to eE:NumMessages: pcError = pcError + cDelimter + e:GetMessage(iLoop) . end. end catch. This works better for me (but again, as Brian said, we're all individuals). -- peter From: Jeff Ledbetter [mailto:bounce-jeffledbetter@community.progress.com] Sent: Wednesday, 20 May, 2015 20:30 To: TU.OE.Development@community.progress.com Subject: RE: [Technical Users - OE Development] Simple Error Handling RE: Simple Error Handling Reply by Jeff Ledbetter “..but I prefer not to have case statements on type in catch blocks.” Why? What if it does the job? Sometimes it helps integrate older and new code.. CATCH e AS Progress.Lang.Error: IF TYPE-OF (e,AppError) THEN pcError = CAST (e,AppError):returnValue. IF TYPE-OF (e,SysError) THEN pcError = DYNAMIC-FUNCTION ( 'fnRtbErrorHandlerObject' , CAST (e,SysError)). END CATCH . Jeff Ledbetter www.roundtable-software.com email: jeff.ledbetter@roundtable-software.com skype: jeff.ledbetter From: Peter Judge [ mailto:bounce-pjudge@community.progress.com ] Sent: Wednesday, May 20, 2015 7:20 PM To: TU.OE.Development@community.progress.com Subject: RE: [Technical Users - OE Development] Simple Error Handling RE: Simple Error Handling Reply by Peter Judge Catching Error and AppError will catch everything. The only reason for AppError is for the ReturnValue , and for that you can work around it (by adding a message number). Since AppError implements Error, a catch Error block will catch those too, but I prefer not to have case statements on type in catch blocks. -- peter From: Thomas Mercer-Hursh [ mailto:bounce-tamhas@community.progress.com ] Sent: Wednesday, 20 May, 2015 17:30 To: TU.OE.Development@community.progress.com Subject: [Technical Users - OE Development] Simple Error Handling Simple Error Handling Thread created by Thomas Mercer-Hursh I keep learning more about error handling ... by discovering things that I didn't know. I started out my current project with catch blocks for AppError and SysError. The former logging ReturnValue and the latter logging GetMessages and the CallStack. Then, because of .NET errors from Proparse, it was suggested that I add a catch block for just Error which also included GetMessages and CallStack. This seemed to help. But, now some new questions. Having gone back to the manual because of some issues, I see that Error is an interface, not a superclass. So, I'm wondering if my third catch block above shouldn't be for ProError instead. Would it make any difference? I am currently doing some little batch utilities which don't have all the logging of the main project. So, I thought I would just put in a simple catch block for Error and dump the GetMessages and CallStack to the output file in the unlikely event that something went wrong. But, I find that GetMessages doesn't give one the ReturnValue if I throw an AppError. So, does this mean that I need at least two catch blocks for AppError and Error (or ProError)? Or do I actually need all three? Stop receiving emails on this subject. Flag this post as spam/abuse. Stop receiving emails on this subject. Flag this post as spam/abuse. Stop receiving emails on this subject. Flag this post as spam/abuse. Stop receiving emails on this subject. Flag this post as spam/abuse.
Continue reading...
Both work equally well. Catch eAE as AppError: pcError = eAE:returnVAlue. End catch. Catch eSE as SysError: pcError = {fnarg fnRtbErrorHandlerObject eSE}. End catch. Catch eE as Error: Do iLoop = 1 to eE:NumMessages: pcError = pcError + cDelimter + e:GetMessage(iLoop) . end. end catch. This works better for me (but again, as Brian said, we're all individuals). -- peter From: Jeff Ledbetter [mailto:bounce-jeffledbetter@community.progress.com] Sent: Wednesday, 20 May, 2015 20:30 To: TU.OE.Development@community.progress.com Subject: RE: [Technical Users - OE Development] Simple Error Handling RE: Simple Error Handling Reply by Jeff Ledbetter “..but I prefer not to have case statements on type in catch blocks.” Why? What if it does the job? Sometimes it helps integrate older and new code.. CATCH e AS Progress.Lang.Error: IF TYPE-OF (e,AppError) THEN pcError = CAST (e,AppError):returnValue. IF TYPE-OF (e,SysError) THEN pcError = DYNAMIC-FUNCTION ( 'fnRtbErrorHandlerObject' , CAST (e,SysError)). END CATCH . Jeff Ledbetter www.roundtable-software.com email: jeff.ledbetter@roundtable-software.com skype: jeff.ledbetter From: Peter Judge [ mailto:bounce-pjudge@community.progress.com ] Sent: Wednesday, May 20, 2015 7:20 PM To: TU.OE.Development@community.progress.com Subject: RE: [Technical Users - OE Development] Simple Error Handling RE: Simple Error Handling Reply by Peter Judge Catching Error and AppError will catch everything. The only reason for AppError is for the ReturnValue , and for that you can work around it (by adding a message number). Since AppError implements Error, a catch Error block will catch those too, but I prefer not to have case statements on type in catch blocks. -- peter From: Thomas Mercer-Hursh [ mailto:bounce-tamhas@community.progress.com ] Sent: Wednesday, 20 May, 2015 17:30 To: TU.OE.Development@community.progress.com Subject: [Technical Users - OE Development] Simple Error Handling Simple Error Handling Thread created by Thomas Mercer-Hursh I keep learning more about error handling ... by discovering things that I didn't know. I started out my current project with catch blocks for AppError and SysError. The former logging ReturnValue and the latter logging GetMessages and the CallStack. Then, because of .NET errors from Proparse, it was suggested that I add a catch block for just Error which also included GetMessages and CallStack. This seemed to help. But, now some new questions. Having gone back to the manual because of some issues, I see that Error is an interface, not a superclass. So, I'm wondering if my third catch block above shouldn't be for ProError instead. Would it make any difference? I am currently doing some little batch utilities which don't have all the logging of the main project. So, I thought I would just put in a simple catch block for Error and dump the GetMessages and CallStack to the output file in the unlikely event that something went wrong. But, I find that GetMessages doesn't give one the ReturnValue if I throw an AppError. So, does this mean that I need at least two catch blocks for AppError and Error (or ProError)? Or do I actually need all three? Stop receiving emails on this subject. Flag this post as spam/abuse. Stop receiving emails on this subject. Flag this post as spam/abuse. Stop receiving emails on this subject. Flag this post as spam/abuse. Stop receiving emails on this subject. Flag this post as spam/abuse.Continue reading...