Project

General

Profile

Bug #919

Exception handler: Util's logAndThrow method prefixes an "Error 500" to the intended user message

Added by Mick Van Fossen almost 7 years ago. Updated almost 7 years ago.

Status:
New
Priority:
Normal
Assignee:
Mike Stults
Target version:
2.4.2
Start date:
11/14/2017
Due date:
% Done:

0%

Estimated time:
Resolution:
Fixed

Description

Hi Mike: A request with a bogus Station name for instance is expected to come back with a "NoDataFoundException". As with other exceptions, I use the Util.logAndThrowException() method passing in a Status.NOT_FOUND or Status.NO_CONTENT.

I get the following which I suppose could confuse the user ...

Error 500: HTTP 204 No Content

Request:
http://localhost:8081/rrds/1/query?sta=NONE&start=2016-01-01&end=2016-01-01T01:00:00&nodata=404&max_gap=0&format=verbosereport

Request Submitted:
2017/11/14 22:07:42 UTC

Service version:
Service: rrds  version: 1.0.6

And here is the "repro" case (code snippet) just to show you what I'm doing:

catch (edu.iris.dmc.service.NoDataFoundException e) {
    logger.info(e);
    if (ri.perRequestUse404for204 == true) {
        Util.logAndThrowException(ri, Status.NOT_FOUND, "Not found.");
    } else {
        Util.logAndThrowException(ri, Status.NO_CONTENT, "No content.");
    }
}

History

#1 Updated by Mick Van Fossen almost 7 years ago

I should have expanded that code above. The theoretical repro is more like this .. I have a outer try-catch surrounding it all. Something like ....

try {
      //
      // Bunch o' code here. My call to the StationService throws an edu.iris.dmc.service.NoDataFoundException
      //
   try {

   } catch (edu.iris.dmc.service.NoDataFoundException | edu.iris.dmc.mustang.service.NoDataFoundException e) {
       logger.info(e);
       if (ri.perRequestUse404for204 == true) {
           Util.logAndThrowException(ri, Status.NOT_FOUND, "Not found.");
       } else {
           Util.logAndThrowException(ri, Status.NO_CONTENT, "No content.");
       }
   }

} catch {Exception e) {
   // At a breakpoint here, 'e' is of type ServiceShellException & detailedMessage = "HTTP 204 No Content" 
   // After this throw the program finishes with the user seeing "Error 500: HTTP 204 No Content" 
   throw e;
}

#2 Updated by Mick Van Fossen almost 7 years ago

CORRECTION. "Bunch o' code" should be in the inner try. OY!

try {

   try {
        //
        // Bunch o' code here. My call to the StationService throws an edu.iris.dmc.service.NoDataFoundException
        //
   } catch (edu.iris.dmc.service.NoDataFoundException | edu.iris.dmc.mustang.service.NoDataFoundException e) {
       logger.info(e);
       if (ri.perRequestUse404for204 == true) {
           Util.logAndThrowException(ri, Status.NOT_FOUND, "Not found.");
       } else {
           Util.logAndThrowException(ri, Status.NO_CONTENT, "No content.");
       }
   }

} catch {Exception e) {
   // At a breakpoint here, 'e' is of type ServiceShellException & detailedMessage = "HTTP 204 No Content" 
   // After this throw the program finishes with the user seeing "Error 500: HTTP 204 No Content" 
   throw e;
}

#3 Updated by Mike Stults almost 7 years ago

A similar error message to the original error messages reported has been replicated with a call like this
Util.logAndThrowException(ri, FdsnStatus.Status.INTERNAL_SERVER_ERROR, e.getMessage());
in place of
Throw(e)

The issue being that the base class (i.e. javax.ws.rs.WebApplicationException, not WSS code) only returns a short string in e.getMessage(), not the full FDSN message created in the original throwable, which should be accessible with e.getCause().getMessage(). However, this would lead to an FDSN message inside an FDSN message.
Also, Util.logAndThrowException does not implement the standard WSS, FDSN rules, thus things like perRequestUse404for204 will appear not to work and possibly other subtle, non- standard behaviors may occur, like headers not getting set.

Util.logAndThrowException should not be used inside an IrisProcessor object, in general, this method should be private, but was left public for historical reasons. (maybe the reasons should be looked at again)

The better solution is to remove all use of Util.logAndThrowException, and replace respective code with one of the processError factory methods in IrisProcessingResult.

#4 Updated by Mike Stults almost 7 years ago

  • Resolution set to Fixed
  • Target version set to 2.4.2

Added fix for exception handling and fix for cfg flag use404For204 per endpoint

2017-11-28 589233e (Mike Stults): (HEAD > master, tag: v2.4.2, origin/master, origin/HEAD) - issue 919 - Util.adjustByCfg to ServiceShellException and ri.appConfig.isUse404For204Enabled(epName) to ReqestInfo to enable similar logic in exceptions as successess

Also available in: Atom PDF