This should never happen

Post by Aaargh20318 » Thu, Mar 31, 2016, 2:30 PM UTC

masklinn wrote: post #95

Aaargh20318 wrote: post #84

Earlier quoted context omitted.

It's also for cases when you know it can't happen. For example, Java's String class has a method public byte[] getBytes(String charsetName) throws UnsupportedEncodingException Since it can throw a checked exception you have to catch it, which generally is fine, but consider this case: someString.getBytes("UTF-8"); This call can never fail (support for UTF-8 encoding is required in Java) but in my case I have to do so…

FWIW getBytes(Charset) doesn't throw, and there's a base set of charsets in StandardCharsets (1.7+): someString.getBytes(StandardCharsets.UTF_8); (Charset.forName doesn't throw either, StandardCharsets avoid stringly-typed code but it's not available on 1.6 so if you're still stuck there Charset.forName works)

Post by zodPod » Thu, Mar 31, 2016, 2:34 PM UTC

FiatLuxDave wrote: post #94

My favorite example of a "this should never happen" error was when I got a call from a customer, who started the conversation by asking, "Who is Brian?". I was caught a bit off guard, but I assumed the customer must know someone at the company, since Brian was the name of the previous electrical engineer/firmware programmer. So, I told them that Brian didn't work here any more, but was there anything that I could hel…

Post by cptskippy » Thu, Mar 31, 2016, 2:35 PM UTC

Post by ben_pr » Thu, Mar 31, 2016, 2:41 PM UTC

Post by igravious » Thu, Mar 31, 2016, 2:43 PM UTC

Someone1234 wrote: post #102

dzdt wrote: post #24

"This should never happen" is a design pattern of defensive programming. This is the same pattern for assert. The usual use is to catch errors caused by misuse of a method. There is some invariant that the method assumes but is not enforced by the type signature of the interface. So if something goes wrong in outside code, or someone tries to use the method incorrectly, the invariant is not satisfied. When you catch…

I agree that it does demonstrate defensive programming. But can I also just add that the error message remains unhelpful and outright "bad." You should absolutely have checks for "impossible" situations, but when those checks fail you need some way of determining which check failed (and cannot always assume you'll have stack backtrace, in particular if an end-user is telling you the error message). For example you co…