Question Re: try... catch... around everything? in Technology Q&A

try... catch... around everything?

Former Member — Wed, 20 Apr 2016 12:31:39 GMT

We're having troubles with application crashes, some are probably due to PowerBuilder itself, many are probably due to our code having issues under certain circumstances. So I have the following questions:

1. Does anyone know if it possible to put a try... catch... around say the application open event and therefore catch all unexpected crashes? In which case we may be able to log the error and at least exit gracefully in some manner

2. Does anyone know a way of making Powerbuilder crash on command? I mean the PBVM itself? I was thinking to try a divide by zero error, but I assume this is captured by the PBVM itself and handled more gracefully than a PBVM crash. I guess I could just create a zillion datastores until Windows runs out of memory.

Thanks

Re: try... catch... around everything?

Former Member — Wed, 20 Apr 2016 12:50:38 GMT

Hi Aron;

Q1: try... catch... around say the application open event

A1: That would only catch an error in the processing chain of the Open event. Once the Open event is completed, the Try..Catch would be out-of-scope.

Do you have proper code in the SystemError event of the Application object class to intercept & log any errors?

Q2: Does anyone know a way of making PowerBuilder crash on command?

A2: Try the undocumented GPF ( ) method.

Regards ... Chris

Re: try... catch... around everything?

Former Member — Wed, 20 Apr 2016 12:56:01 GMT

Isn't there any top level code in PowerBuilder that is in scope for the whole running of an application? Boy, I've been doing too much C# recently, starting to forget everything about PowerBuilder!

I know we have something in the SystemError event, I shall have to have a look at it. It was written by someone else many, many years ago.

Re: try... catch... around everything?

Former Member — Wed, 20 Apr 2016 13:39:47 GMT

Hi Aron

Crashes are usually caused by something in your code, or at least the work around can be done there

I'm guessing that the problem is occurring in production and the users are not able to give you a clue as to what they are doing. Certainly the system error event traps "controlled" errors, but if the PB VM is bombing then its a different game.

What is in the event log? Do you get a memory dump? You could get SAP support to analyse the memory dump to tell you what is happening when it crashes. That might help.

Good luck

David

Re: try... catch... around everything?

Former Member — Wed, 20 Apr 2016 13:44:14 GMT

If you call a Windows API function that has a string argument that is by ref and you fail to initialize the string to a size large enough to hold the result then you will get an abort.

Re: try... catch... around everything?

Former Member — Wed, 20 Apr 2016 13:47:50 GMT

Q: Isn't there any top level code in PowerBuilder that is in scope for the whole running of an application?

A: No, not in a visible GUI application where the processing is dependent on an Event driven model. The only entity in control in this case would be the PBVM itself. In a Batch application where your basically in a tight processing loop - then you could wrap the Loop in a Try..Catch as typically coming out of this loop the batch application closes.

Speaking of the PBVM though ... have you tried running your PB application EXE using the internal tracing option? FYI: Invoke the executable file using the /pbdebug command-line switch, for example: EXEFILE /pbdebug

The trace file might tell you at the time of the crash at least what was processing and where within your application and/or PBVM when the non-recoverable issue happened.

Food for thought.

Re: try... catch... around everything?

Former Member — Wed, 20 Apr 2016 13:49:19 GMT

The extra complication is that it's happening for a Citrix user and they seems to be kicked of Citrix but then the account is left hanging and an IT person has to kill it. As you guessed, the customers can't tell us where it happened or if there was an error message on the screen at the time or anything useful.

I'm kinda hoping I can at least shut down the application properly so the Citrix session isn't held at least. I'll have to check the SystemError event and see what it's doing. But first I need to get it to crash in hopefully a similar way to the customer.

Re: try... catch... around everything?

Former Member — Wed, 20 Apr 2016 13:50:48 GMT

Ah yes forgot about that, but if I remember rightly it really, really slows everything down, to the point where it's impossible to use?

Re: try... catch... around everything?

Former Member — Wed, 20 Apr 2016 13:51:18 GMT

Thanks Roland, that's a great example, I'll give it a go!

Re: try... catch... around everything?

Former Member — Wed, 20 Apr 2016 13:52:04 GMT

FWIW: Make sure that the SystemError event code is using a HALT command and not a HALT CLOSE if it determines that the application can not continue. Using the Halt command with a close could either crash or hang-up the PB application.

Re: try... catch... around everything?

Former Member — Wed, 20 Apr 2016 17:04:29 GMT

Just has a quick look at the code in SystemError, it doesn't feel right to me. It's calling uf_system_error on u_nvo_application which then opens a Window to show the error message. If there's been a system error then I'm not sure that's the safest thing to try since who knows what state the application is in.It then attempts to close the application normally.

I'd be very interested to know what kind of things other people do in their SystemError events?

Thanks.

Re: try... catch... around everything?

Former Member — Wed, 20 Apr 2016 17:37:00 GMT

Hi Aron;

FWIW: Here is what my STD Integrated Framework does in the System Error ...

1) Log the error details 1st & foremost

for example:

// Write diagnostics to the log
ii_rc = THIS.of_get_message( 84, ls_title, ls_msg )
THIS.of_write_log ( ls_msg )
THIS.of_write_log ( " Error Number ...... " + String (Error.Number))
THIS.of_write_log ( " Error Line .......... " + String (Error.Line))
THIS.of_write_log ( " Error Object ....... " + Error.Object)
THIS.of_write_log ( " Error Event ........ " + Error.ObjectEvent)
THIS.of_write_log ( " Error Message .... " + Error.Text)

2) If running in "silent" mode (aka Batch, Service, Taskbar, etc application = > HALT

3) After logging & running as either an Appeon Web, Appeon Mobile or native GUI application, put out a graceful generic user message and ask them if they want to continue.

Note: Turn on silent mode here! If the MSG Box dies and the SystemError event is entered again - then the code will take the Step#2 path.

4) MessageBox to User to continue (Yes/No)?

5) YES=> Log the user's response to #4 & exit event.

NO => eMail log to support, Log that action & then HALT

HTH

Regards ... Chris

Re: try... catch... around everything?

Former Member — Wed, 20 Apr 2016 19:10:20 GMT

I like to record system and datawindow errors in an error table in the database. Then add a window to the app where you can view the errors.

Re: try... catch... around everything?

Former Member — Thu, 21 Apr 2016 08:19:58 GMT

We email any errors to our Support desk, This avoids asking the user what happened We are also able to proactively fix the problem or more likely report it to their IT department as it's their problem

Re: try... catch... around everything?

arnd_schmidt — Thu, 21 Apr 2016 10:34:41 GMT

Typically you get a GPF when the call stack explodes because of too much recursion depth, like:

public subroutine of_gpf ()

of_GPF()

end subroutine

Sure... that is bad PowerBuilder Code. But you never know, when it blows up.

Re: try... catch... around everything?

Former Member — Thu, 21 Apr 2016 21:12:36 GMT

Good idea thanks

Re: try... catch... around everything?

Former Member — Thu, 21 Apr 2016 21:15:39 GMT

Thanks everyone, I guess this means just because you had a System Error it doesn't mean PowerBuilder itself is unstable, as you still seem to be able to do things like write to logs and send emails. So our System Error code may not be too bad.

We did have a number of timer events in our application and I suspect these were guilty of causing some of the crashes. They have, so I'm told, been cleaned up a bit, so hopefully that will help.