Someone gave me a web method that return a boolean.
The Boolean tells me if the operation went well.
True means everything went well
False means something went wrong

But
It throws exception when something went wrong.
Basically they implemented a Boolean system to check if everything is alright but I also have to add a try/catch if something is not right.

wtf...

Better than the 500 when you're no longer authenticated lol even though they are supposed to return the 'you're not authenticated' indication with every call if this happens.. :/

Have you tried finding the author of the method and killing him with your teeth?

That's the only solution I can think of.

Well I'd argue that you should almost never catch exceptions that you did not expect without rethrowing them.

Your situation of course could differ.

@dodomo the point isn't that exceptions are being used

The point is that the method returns a value indicating success, when it throws on failure anyway

@Krokoklemme gotcha 😁

In that case kill it with fire!

It makes sense.
Think of it as http codes.

If you have a method that can return 2xx, 3xx 5xx, etc. You know which ones are errors right?

Returning a value to tell you what went wrong means all the code executed and covered scenarios worked.

Now, imagine the method failed to even. Connect to the internet, do you want an http code or an exception?

This 'pathern' is good, I agree it might not be the best for your web method, but it it good nevertheless.

@mundo03
Well I'm guessing OP means a scenario where the response looks something like this:
HttpStatusCode 200
{
errorMessage: "something went wrong "
}

That's obviously not a good pattern.

@dodomo
I still think it is good enogh, scalable for more results.

The developer is the responsable to handle exception on whatever is being built. You would not want to rely on some third-party code to control what is handled and what is not handled.
Specially if the 3rd party is some quick shit that you should be implementing anyway.