catchError Not working when returning error 500 from web-api

Viewed 952

After trying more complex scenarios, without solution I return to basics:

I have a web-api controller that when returning error 500, I would like the client to catch it.

For some reason - this isn't happening - I probably missing something here.

The mechanism work perfectly when the controller in his regular state.

When running this code - in the console, I can see: the error 500 message and an error and error claiming:"You provided an invalid object where a stream was expected...".

what am I missing here ?

This is my code (written by hand, not copy+paste - ignore typo errors):

Controller returning exception on purpose:

public IActionResult getSomeErrorAsTest()
{
    try
    {
        /*usually it does something on the server*/
        throw new Exception("Serer error");
    }
    catch(Exception ex)
    {
        return StatusCode(StatusCodes.Status500InternalServerError, new List<string>());
        //throw ex;
    }
}

Angular service:

export class MyService
{
    getData()
    {
        return this.httpClient.get<void>(<controller url>)
        /*not sure if this part is needed*/
        .pipe
        (
            catchError(this.handleError);
        )
    }
    
    handleError(error : HttpErrorResponse)
    {
        return Observable.throw(error.message || "server error");
    }
}

Consuming Component:

export class myComponent
{
    isGettingData : boolean;
    constructor (private mySrv : MyService)
    ngOnInit()
    {
        this.isGettingData = false;
    }
    public getData()
    {
        this.isGettingData = true; //This is used for indication icon in the Html, in case the server action takes few seconds 
        this.mySrv.getDataFromBackEndServer().subscribe
        (
            result => this.isGettingData = false, 
            error => {
                console.log('eror occured');
                this.isGettingData = false;
            },
            () => console.log('completed')
        );
    }
}
2 Answers

After lots of tests, hair pulling - it figured out that the problem was the HTTP_INTERCEPTORS which probably "fish" the error responses.

Related