This code path leaves entire classes of unhandled parse exceptions on the table. I have a hard time believing this could be intentional. The safest and most concise approach is to use int.TryParse on the inputId and throw if it returns false.

▲

xnorswap 3 days ago | parent [-]

Does it? Int.Parse says it can only return those 2 exceptions or ArgumentNullException, but nulls have been handled already.

https://learn.microsoft.com/en-us/dotnet/api/system.int32.pa...

▲

bob1029 3 days ago | parent [-]

Fine but with all that code we are implying there is some case we don't want to catch for some reason. If any effective parse error should always throw we should simply do that instead of playing games.

	▲	bonesss 2 days ago \| parent [-]
		You’re not accounting for what the example actually does. The example provides exception conformance at the API level and specific logging information for tracing and debugging. It’s not playing games, it’s simplifying details for upstream consumers and explaining their contribution to the issue, while being explicit in its intentioned failure modes and failure behaviour. This code cannot tell callers why the callers have sent it garbage or what to do about that, it is failing and explaining why. Throwing “invalid : bad user id” is substantively different than rethrowing “index out of bounds : no string character at index -1”. The wrapped exception has all the original detail, its just unified and more descriptive.