L
Laura Stern
Guest
First of all, errors do not cause a "crash". An error is an error. If it is unhandled, it will kick you out of the current block context and the application/server continues on. It may be that you have had some unhandled Stop conditions, not errors. But even with that, these do not cause a crash. The process remains intact. If you are at the top of the AppServer call stack, this should cause an error message to be logged and it will kick you out of the procedure, but the process is still there to service subsequent requests. And BTW, starting in 11.7, using -catchStop (in 12 it will be the default), you can also catch unexpected Stop conditions with the same Progress.Lang.Error CATCH block. That is because you will get a Stop object that implements the Progress.Lang.Error interface. If you have a CATCH block at the "outer-most PersistentProcedure.p which is used for app server entry" but it does not handle some condition, all that means is that the error message will be issued and go to the log file rather than the error going to your CATCH block which then presumably issues a message which goes to the log file. Though I appreciate that maybe you log extra information from your CATCH block (see below regarding -debugalert). Even though in general, you want to use BLOCK-LEVEL ON ERROR UNDO, THROW when doing structured error handling, you should NOT have this directive at the top-most .p that is the app server entry procedure if you never want errors to be thrown back to the client. And in your case, you do not want that because then you then just get the error you are complaining about. If you get a fatal error, I don't think this discussion is relevant. The process (or session for PASOE) will be terminated. I believe if you use -debugalert, any error that is written to the log will show a stack trace. Though, I agree, that if this is an error that has bubbled up from somewhere else, this is not very useful. You need the error stack information from the object itself. If that is not output, that is a valid complaint. I don't know what you mean be a "generic message"? You should definitely at least see the specific error message based on what error occurred. But this whole discussion started with you getting the error "Cannot throw or return error/stop object to remote client because object is not serializable or client does not support it". I will repeat - just don't use BLOCK-LEVEL ON ERROR UNDO, THROW in the top level procedure. That is just wrong for this .Net Open Client scenario. And that is what is masking what the real error is. If you weren't trying to throw it out of the server, you will see the real error in the log.
Continue reading...
Continue reading...