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

More polite reporting of NotSerializableException

    XMLWordPrintable

Details

    Description

      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.

      Attachments

        Issue Links

          Activity

            jglick 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
            jglick 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

            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.

            tg9541 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.

            People

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

              Dates

                Created:
                Updated: