Trapping errors from Proparse

Posted by Thomas Mercer-Hursh on 19-May-2015 11:24

I am doing some work adding Proparse to ABL2DB in order to expand its capabilities.  The old Proparse had no version 11.x syntax, but Mike Fechner and Marian Edu added some and now John Green has added a couple more bits.  The problem we are having is that our current error handling is providing some help, but is not diagnostic for all errors.  I will put our current catch routine at the end.

Sometimes we will get an error message from Proparse with a line number in the program being parsed and a token, e.g., TABLE-SCAN, which was not in Proparse prior to version 1117.  In that case, we know exactly what syntax is the problem and can look at the code to tie it down.  E.g., in one case the token was LIKE and the line number pointed to a parameter definition for a method so that we knew that the problem was using LIKE in a method parameter definition.

But, we are also getting two types of errors that are not providing this information.  These are either org.prorefactor.refactor.RefactorException or a java.lang.NullPointerException.  In the latter case, we sometimes get a call stack, but not always and the call stack is not really helping me to find the source of the error.   Is there any additional error handling we can put in that would be likely to help (other than modifying Proparse itself, which is not in my control).

My current top level catch blocks are:

		catch eobAppError as Progress.Lang.AppError:
			log-manager:write-message ( eobAppError:ReturnValue ).	
			delete object eobAppError.
		end catch.
	
		catch eobSysError as Progress.Lang.SysError :
			log-manager:write-message(substitute("Unexpected Exception: &1", eobSysError:getMessage(1)), "SysERROR").
			if eobSysError:NumMessages > 1
			then do inWhich = 2 to eobSysError:NumMessages:
				log-manager:write-message(substitute("Unexpected Exception (cont.): &1", eobSysError:getMessage(inWhich)), "SysERROR").
			end.
			do inWhich = 1 to num-entries(eobSysError:CallStack,"~n"):
				log-manager:write-message(entry(inWhich,eobSysError:CallStack,"~n"),"CALLSTACK").
			end.
			delete object eobSysError no-error.
		end catch.
		
    catch eobOtherError as Progress.Lang.Error :
      log-manager:write-message(substitute("Other error: &2", eobOtherError:getMessage(1))).  
      if eobOtherError:NumMessages > 1
      then do inWhich = 2 to eobOtherError:NumMessages:
        log-manager:write-message(substitute("Unexpected Exception (cont.): &1", eobOtherError:getMessage(inWhich)), "OtherERROR").
      end.
      do inWhich = 1 to num-entries(eobOtherError:CallStack,"~n"):
        log-manager:write-message(entry(inWhich,eobOtherError:CallStack,"~n"),"CALLSTACK").
      end.
      delete object eobOtherError no-error.
    end catch.


All Replies

Posted by Mike Fechner on 19-May-2015 11:28

Learn Java. Add catch blocks there. Add more context to the errors. Throw those better error from Java to ABL. That allows you to provide more data to ABL code handling those errors. Period.

You like to talk about systems: When the system that throws the error does not provide more details, then the  recipient is out of luck.

From my own experience with proparse, one further recommendation: It does not like code in mixed code-pages. 


Von: Thomas Mercer-Hursh <bounce-tamhas@community.progress.com>
Antworten an: "TU.OE.Development@community.progress.com" <TU.OE.Development@community.progress.com>
Datum: Dienstag, 19. Mai 2015 18:25
An: "TU.OE.Development@community.progress.com" <TU.OE.Development@community.progress.com>
Betreff: [Technical Users - OE Development] Trapping errors from Proparse

Thread created by Thomas Mercer-Hursh

I am doing some work adding Proparse to ABL2DB in order to expand its capabilities.  The old Proparse had no version 11.x syntax, but Mike Fechner and Marian Edu added some and now John Green has added a couple more bits.  The problem we are having is that our current error handling is providing some help, but is not diagnostic for all errors.  I will put our current catch routine at the end.

Sometimes we will get an error message from Proparse with a line number in the program being parsed and a token, e.g., TABLE-SCAN, which was not in Proparse prior to version 1117.  In that case, we know exactly what syntax is the problem and can look at the code to tie it down.  E.g., in one case the token was LIKE and the line number pointed to a parameter definition for a method so that we knew that the problem was using LIKE in a method parameter definition.

But, we are also getting two types of errors that are not providing this information.  These are either org.prorefactor.refactor.RefactorException or a java.lang.NullPointerException.  In the latter case, we sometimes get a call stack, but not always and the call stack is not really helping me to find the source of the error.   Is there any additional error handling we can put in that would be likely to help (other than modifying Proparse itself, which is not in my control).

My current top level catch blocks are:

		catch eobAppError as Progress.Lang.AppError:
			log-manager:write-message ( eobAppError:ReturnValue ).	
			delete object eobAppError.
		end catch.
	
		catch eobSysError as Progress.Lang.SysError :
			log-manager:write-message(substitute("Unexpected Exception: &1", eobSysError:getMessage(1)), "SysERROR").
			if eobSysError:NumMessages > 1
			then do inWhich = 2 to eobSysError:NumMessages:
				log-manager:write-message(substitute("Unexpected Exception (cont.): &1", eobSysError:getMessage(inWhich)), "SysERROR").
			end.
			do inWhich = 1 to num-entries(eobSysError:CallStack,"~n"):
				log-manager:write-message(entry(inWhich,eobSysError:CallStack,"~n"),"CALLSTACK").
			end.
			delete object eobSysError no-error.
		end catch.
		
    catch eobOtherError as Progress.Lang.Error :
      log-manager:write-message(substitute("Other error: &2", eobOtherError:getMessage(1))).  
      if eobOtherError:NumMessages > 1
      then do inWhich = 2 to eobOtherError:NumMessages:
        log-manager:write-message(substitute("Unexpected Exception (cont.): &1", eobOtherError:getMessage(inWhich)), "OtherERROR").
      end.
      do inWhich = 1 to num-entries(eobOtherError:CallStack,"~n"):
        log-manager:write-message(entry(inWhich,eobOtherError:CallStack,"~n"),"CALLSTACK").
      end.
      delete object eobOtherError no-error.
    end catch.


Stop receiving emails on this subject.

Flag this post as spam/abuse.

Posted by Thomas Mercer-Hursh on 19-May-2015 11:42

I have yet to succeed in building Proparse, so even if I modified it, I couldn't produce a new version ... and certainly not in the short run.  I recognize that the better solution is better errors from Proparse, but for now, that is out of my control, so my only immediate route of action is to do something from the ABL side, if there is anything to do.

Posted by Mike Fechner on 19-May-2015 11:44

There is not I am afraid.
 
 
Von: Thomas Mercer-Hursh [mailto:bounce-tamhas@community.progress.com]
Gesendet: Dienstag, 19. Mai 2015 18:43
An: TU.OE.Development@community.progress.com
Betreff: RE: [Technical Users - OE Development] Trapping errors from Proparse
 
Reply by Thomas Mercer-Hursh

I have yet to succeed in building Proparse, so even if I modified it, I couldn't produce a new version ... and certainly not in the short run.  I recognize that the better solution is better errors from Proparse, but for now, that is out of my control, so my only immediate route of action is to do something from the ABL side, if there is anything to do.

Stop receiving emails on this subject.

Flag this post as spam/abuse.

Posted by Thomas Mercer-Hursh on 19-May-2015 11:56

So, no point in adding other catch blocks other than to give a more user friendly message with no actual useful additional information?

Posted by Mike Fechner on 19-May-2015 12:00

To me it makes a substantial different to know if there is a classic unhandled runtime error in the tool and I might have to verify code-pages of my code or so.
Or if there is just some unsupported syntax.

The strategy for the user to fix this is different.

Von: Thomas Mercer-Hursh <bounce-tamhas@community.progress.com>
Antworten an: "TU.OE.Development@community.progress.com" <TU.OE.Development@community.progress.com>
Datum: Dienstag, 19. Mai 2015 18:57
An: "TU.OE.Development@community.progress.com" <TU.OE.Development@community.progress.com>
Betreff: RE: [Technical Users - OE Development] Trapping errors from Proparse

Reply by Thomas Mercer-Hursh

So, no point in adding other catch blocks other than to give a more user friendly message with no actual useful additional information?

Stop receiving emails on this subject.

Flag this post as spam/abuse.

Posted by Thomas Mercer-Hursh on 19-May-2015 12:08

No question.  But, how can I tell the difference from ABL?  Isn't this just saying that the error handling in Proparse could be better?

Posted by Mike Fechner on 19-May-2015 12:10

We can handle this in infinitive loop: You can't. You can only guess by the type (aka class) of error.

Von meinem Windows Phone gesendet

Von: Thomas Mercer-Hursh
Gesendet: ‎19.‎05.‎2015 19:09
An: TU.OE.Development@community.progress.com
Betreff: RE: [Technical Users - OE Development] Trapping errors from Proparse

Reply by Thomas Mercer-Hursh

No question.  But, how can I tell the difference from ABL?  Isn't this just saying that the error handling in Proparse could be better?

Stop receiving emails on this subject.

Flag this post as spam/abuse.

Posted by Thomas Mercer-Hursh on 19-May-2015 12:31

I don't currently have any guesses based on ProrefactorException vs NullPointerException.

Posted by Mike Fechner on 19-May-2015 13:53

The typical RefactorException – so when it’s an not understood piece of syntax is pretty nice: 1:5 are line and column of the token that fails to compile.
 
The .NET Stack Trace points to the location in the Java code (thanks to IKVM).
 

This thread is closed