HttpException returns an ugly message.

[VictorioBerra]

HttpException calls base(message), if message is null you get something ugly like:

Exception of type 'XYZ+HttpException' was thrown.

This is the exposed here https://github.com/Dotnet-Boxed/Framework/blob/master/Source/Boxed.AspNetCore/Middleware/HttpExceptionMiddleware.cs#L29

Also:

It is important to note that ReasonPhrase is not a thing in HTTP/2. Why not have something like this?

            if (exception is HttpException re)
            {
                context.Response.StatusCode = (int)re.StatusCode;
                var result = JsonConvert.SerializeObject(new
                {
                    errors = re.Message
                });
                await context.Response.WriteAsync(result);
            }

and then in HttpException base(message ?? string.Empty)

[RehanSaeed]

Honestly, I'm not a fan of using the message anywhere. I only put reason phrase in there because that is what MVC5 was doing. Exceptions can contain sensitive data and I don't think they should ever be exposed to the clients.

[cannehag]

Hi, I would like to question this change a bit @RehanSaeed. Removing the possibility to supply a reason is causing us some issues since this is the way we communicate WHY an exception occur to consumers of our apis.
I just sent a pull request where I implemented opt-in support for this, hope you think it looks good!

[RehanSaeed]

@cannehag Merged your PR. I thought it was reasonable, given the breaking nature of the change.

That said, using exceptions to return error messages is not the best strategy. There are even whole new programming languages like Rust that don't have exceptions for this very reason and force you to return errors alongside the result of your function in the success case. It's also slower.

Secondly, showing exception messages to users can be a security problem if you're not very careful because exceptions can sometimes contain sensitive data about the app or even just info about the internals that might help an attacker in some way.

I've used exceptions for error messages in the past myself and have debated even removing this middleware as I no longer think it's a good idea to use it.

[cannehag]

I agree with that on same parts. But since exception handling is in the nature of .NET languages, I think it should be free to use. The security risk is always there, and having frameworks reduce the risk is a good thing. That is why opting in is a better approach, if you understand the risk :)
In this particular case I do think the middleware is doing a good job in just returning the code and message and not the entire exception.
Thanks for the merge, any ETA on the release @RehanSaeed ?

[VictorioBerra]

@cannehag @RehanSaeed Yeah, I wish .NET would offer some better alternatives to throwing a custom exception and then using middleware to catch and expose it. That is such an easy way to handle things. Until there is an easier way a lot of people will want to go down this path.

Jonas has a point that exceptions are a first-class citizen in ASPNET Core.

force you to return errors alongside the result of your function

@RehanSaeed Do you have an articles or examples for doing it the "Rust way" in C#?

I wouldn't want to have to create a DTO for every single one of my methods that has an Errors property. That would be too much work.

[RehanSaeed]

@RehanSaeed Do you have an articles or examples for doing it the "Rust way" in C#?

Use a custom class containing your success and error properties. Or you can use modern tuples to save on having to write extra classes.

[RehanSaeed]

Released