The responseCode field is only populated on error through the (message, responseCode) interface. Can you provide me a test where the responseCode is lost as you suggest? I'm confused how adding the getMessage() to the constructor will help your situation. Is the issue is nested NetStorageExceptions?

Hello,
Please consider the following use case:

Checking that a file exists in NetStorage

Description:
As a user, I would like to check if a file was already uploaded into NetStorage service.
I expect to do that by calling the stat method of NetStorage class with the file's supposed path.

Considerations:
The system architecture is cloud based and deals with high volume of concurrent requests.
Each file storage request should be carefully considered to avoid latency and performance bottle necks.
Therefore, it is crucial to validate that a file doesn't already exist on server before attempting to upload it.

Possible execution path ( assuming file doesn't exist on storage) :

NetStorage::stat("myFile"):195 ->NetStorage::execute("GET","myFile","stat"):203 ->NetStorageCMSV35Signer::execute(...) -> this method will throw a NetStorageException (via validate method) with a responseCode 404 (if I recall well enough) indicating the requested file was not found on storage.
This exception will then bubble up the chain until caught by NetStorage:70 and re-thrown again using the mentioned constructor, losing in the process it's response code and replacing it with default value of -1 (not a standard HTTP code).

This behaviour in new. It breaks backwards compatibility with pre 3.6.x versions which expect to receive the correct response code from a NetStorage exception (if such a code exists).
Another valid example could be in the case the server answers with an HTTP 403 exception (Unauthorized) due to bad credentials, I would then want to inform system admin that those credentials should be revalidated through Akamai support, but I won't be able to know that through code unless I am expected to explore my stack information.

My suggested solution:
NetStorageException contains the following constructor:
NetStorageException(String message, Throwable cause) which differentiates NetStorage exceptions from generic exceptions, it uses reflection to query the type of the Throwable provided and if it detects it to be of type NetStorage, it preserves it's statusCode field.
By delegating to this constructor we will be able to maintain current exception handling structure along with preserving relevant exception information which pre-existed before code was changed.

I hope my answer satisfies any doubts you may have.

Best regards,
Ori Libhaber
Harman Connected Services

Hello,

Any progress regarding this pull request?
If you require more clarifications please let me know.

Best regards,
Ori Libhaber
Harman Connected Services

So the root issue is that NetstorageException extends RequestSigningException. Can you add a) a test case and b) a catch for NetstorageException? This will address my issues and your issue at large.

+1 on this issue

Another use case is the following:

When executing NetStorage::dir("myDir") ->NetStorage::execute("GET","myDir","dir"):203 ->NetStorageCMSV35Signer::execute(...) -> this method will throw a NetStorageException with a responseCode 404 as well.
This exception is also bubbled up in the chain and re-thrown. This loses the response code and again, replaces it with the default value of -1.