Subversion Repositories SmartDukaan

Last modification

• Rev 37742 – 4 h 14 m
• Author: amit

• Log message:

  v2: silence client disconnects and demote 4xx, matching the v1 taxonomy
  
  r37728 added a client-disconnect handler to the v1 GlobalExceptionHandler and the
  flood did not stop: #39 went on adding events, and every one of a 50-event sample
  was from a /v2/ URL. V2GlobalExceptionHandler is scoped
  basePackages="com.spice.profitmandi.web.v2", so v2 responses never reached the v1
  handler at all and fell through to its own handleGenericException at ERROR --
  ~19,900 events, the second largest source on the board.
  
  Worth recording because the first diagnosis was wrong. The theory was that an
  exception raised while the response body is written cannot reach an @ExceptionHandler
  because the response is already committed. It can: DispatcherServlet catches it out of
  ha.handle() and still runs the resolvers. What it cannot do afterwards is WRITE the
  substitute response. The handler runs and logs either way, which is precisely why
  patching the wrong advice class changed nothing.
  
  Adds @ExceptionHandler(IOException.class) here, delegating to the same
  isClientDisconnect test the v1 handler uses -- duplicated rather than shared because
  catalina is provided by the container and is not on this module's compile classpath,
  so ClientAbortException cannot be imported and is matched on simple name plus the
  messages a dead peer actually produces. A genuine IOException (full disk, a broken
  pipe to something that is not the client) matches none of them and keeps its ERROR
  and its 500. Returns null for a disconnect: the connection that would carry a body is
  already gone, and writing to it is what raised this.
  
  Also demotes five sibling handlers in the same file that were logging caller mistakes
  at ERROR, which v1 has logged at WARN since the taxonomy work: business validation,
  missing parameter, type mismatch, malformed body, method not supported, media type
  not supported. v2 never received that pass. The business line also stops attaching a
  stack trace -- a validation has nothing useful in one.
  
  Left at ERROR deliberately, because they are real defects: IllegalArgument, NPE,
  genuine IO failure, and the two catch-alls.