Looking for sample code for throwing error from the AppServer - Forum - OpenEdge Development - Progress Community

Looking for sample code for throwing error from the AppServer

 Forum

Looking for sample code for throwing error from the AppServer

This question is answered

I would like to try this throwing an error from the AppServer to be caught by the client, but I'm not quite sure about the implementation. Help talks about using a SERIALIZABLE class. Can you point me to a sample code?

Thanks, 

Verified Answer
  • CLASS yourpackage.YourError INHERITS Progress.Lang.AppError SERIALIZABLE:
    // properties
    // constructors
     
    END CLASS .
     
    UNDO, THROW NEW yourpackage.YourError ().

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

All Replies
  • CLASS yourpackage.YourError INHERITS Progress.Lang.AppError SERIALIZABLE:
    // properties
    // constructors
     
    END CLASS .
     
    UNDO, THROW NEW yourpackage.YourError ().

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Do you know of any caveat or anything that I should watch out for?

  • Not being on historic releases such as 11.3 or so would help.
     
    Try it. Let us know when you run into issues.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • If your serialzable class contains other types, they must *all* be serializable otherwise you'll get a runtime error.
     
    This becaomes tricky when you have something like
     
    Class MyError inherits AppError serializable:
       Def public property ErrorContext as Progress.Lang.Object get. set.
    End class.
     
    Because you can assign any object (of any type) to that property, you can very easily assign an unserialzable one.
     
    For  ABL built-in serialization, you don't have control of the actual serialization operation (turning the object into bytes/json) which makes working around this hard.
     
     
     
  • Be careful.  If you try to throw it back to the client using...:

      UNDO, THROW NEW yourpackage.YourError ().

    ...then you need to have BLOCK-LEVEL UNDO, THROW at the top of your .p or .cls file.  Otherwise the error will just get raised within its current block context. Or you can do the following from the top-level AppServer procedure:

      RETURN ERROR NEW yourpackage.YourError ().

  • For the RETURN statement, does it behave the same way when just returning a literal string, or does it need to be a ProgressError derived class when using structured error handling?

    Laura Stern

    Be careful.  If you try to throw it back to the client using...:

      UNDO, THROW NEW yourpackage.YourError ().

    ...then you need to have BLOCK-LEVEL UNDO, THROW at the top of your .p or .cls file.  Otherwise the error will just get raised within its current block context. Or you can do the following from the top-level AppServer procedure:

      RETURN ERROR NEW yourpackage.YourError ().

  • I don't know what you mean by "does it behave the same way when just returning a literal string".  if you return an error object instance, it needs to be a class that implements Progress.Lang.Error and it needs to be SERIALIZABLE (which all the system classes are).  That's the same as with UNDO, THROW.  If you just return a literal string, you can catch it on the client as an AppObject where the ReturnValue property will be set to that string value.  Or you can just handle the error the non-structured error-handling way (with DO ON STOP, or whatever), and the RETURN-VALUE function will return that string.

  • I don't know what you mean by "does it behave the same way when just returning a literal string".  if you return an error object instance, it needs to be a class that implements Progress.Lang.Error and it needs to be SERIALIZABLE (which all the system classes are).  That's the same as with UNDO, THROW.  If you just return a literal string, you can catch it on the client as an AppObject where the ReturnValue property will be set to that string value.  Or you can just handle the error the non-structured error-handling way (with DO ON STOP, or whatever), and the RETURN-VALUE function will return that string.

  • Interesting article on the throw keyword: hackernoon.com/the-throw-keyword-was-a-mistake-l9e532di

    More on this f.e.:

    https://www.monitis.com/blog/improving-net-application-performance-part-10-exception-management/
    https://mattwarren.org/2016/12/20/Why-Exceptions-should-be-Exceptional/

  • I had a long post here and I deleted it because this isn't the right thread.  agent_008...if you want to start a new thread, I'll be happy to rant along with you :)

  • You answered my question. I was just wondering if both cases (object or literal) can be processed/handled similarly using structured error handling.

  • Ok, will do.