Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-25925

More polite reporting of NotSerializableException

      If you accidentally store something nonserializable in a local variable, you get a nasty stack trace mentioning org.jboss.marshalling.river.RiverMarshaller.doWriteObject and other things which will make no sense to a user and imply a bug in Workflow rather than in your script.

      RiverWriter should defend better against this. It could replace the bad object with null, after printing a warning in the log. Or it could simply replace it with a pickle that rehydrates to null or throws an exception if you ever resume this flow after a restart. I think replacement with null is preferable since in most cases you did not really need the object to be saved and the flow could have continued without it.

          [JENKINS-25925] More polite reporting of NotSerializableException

          The real problem is that CPS isn't quite Groovy, and what may be perfectly valid CPS code in one scope (e.g. on the top level, or in node('master') {}) is invalid in other places (e.g. when used in a closure in a map for parallel execution).

          Sometimes being polite is the wrong approach. Avoiding surprises is better.

          Thomas Goeppel added a comment - The real problem is that CPS isn't quite Groovy, and what may be perfectly valid CPS code in one scope (e.g. on the top level, or in node('master') {} ) is invalid in other places (e.g. when used in a closure in a map for parallel execution). Sometimes being polite is the wrong approach. Avoiding surprises is better.

          Jesse Glick added a comment -

          Probably what I want to do here is print a warning to the log, then replace with a pickle whose dehydration throws an error. Thus

          • builds which are not resumed will work fine whatever they do
            • but will you will see a warning so you know what to fix as time permits
          • builds which are paused & resumed after the faulty object has been discarded will be fine
          • builds which are paused & resumed while a faulty object is referenced will fail with a relatively clear message

          Jesse Glick added a comment - Probably what I want to do here is print a warning to the log, then replace with a pickle whose dehydration throws an error. Thus builds which are not resumed will work fine whatever they do but will you will see a warning so you know what to fix as time permits builds which are paused & resumed after the faulty object has been discarded will be fine builds which are paused & resumed while a faulty object is referenced will fail with a relatively clear message

            kohsuke Kohsuke Kawaguchi
            jglick Jesse Glick
            Votes:
            7 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated: