Oh yes. A common pattern of error handling called "let's make the exception worse".


Your exception, but worse.


Just make sure you write unit tests… /s




I suspect there might be something which throws some pretty broad exceptions. Here, the exceptions that can be raised are narrowed from Throwable down to IOException and FontFormatException. These would be nicer to handle (the method now throws FontFormatException or IOException, not Throwable) or maybe this is implementing an abstraction which only allows IO and FontFormat exceptions There’s better ways to do it though…




> But what's the point of testing the type and then throwing it casted to the narrowed type? If we just re-throw the Throwable, now our method signature is: ‘void exec() throws Throwable’ If we ensure the type first, now our method signature is: ‘void exec() throws IOException, FontFormatException’ The latter is more explicit on what can go wrong, giving the caller a better hope of dealing with the exception > If we have Throwable > Generic > Specific and we catch Throwable, test the type and it happens to be of type Specific, casting it to Specific and throwing again will not change how any callers handle the Throwable/can test for instance type. The thrown type declared by the method changes from from Throwable to Specific > Not to mention the swallowing of the Throwable at the end. Yeah, this is nasty




Decoded bytecode always looks like this. I think op is looking at the compiled class through a decompiler


Checked exceptions in java. They're a part of the type system.


My guess: checked exceptions. The method might say in its signature it can throw FontFormatException and IOException. So it tells you what errors might occur and you can only use it if you handle the errors it might throw. Solid idea in theory, in practice it leads to nonsense like this. IOException just means nothing here and can't be properly handled. Nowadays many just throw unchecked runtime exceptions and catch all. At least that was my impression from the few java codebases I've seen


*Image Transcription: Code* --- } } catch (Throwable t) { if (t instanceof FontFormatException) { throw (FontFormatException)t; } if (t instanceof IOException) { throw (IOException)t; } Throwable cause = t.getCause(); if (cause instanceof FontFormatException) { throw (FontFormatException)cause; } throw new IOException("Problem reading font data."); } } --- ^^I'm a human volunteer content transcriber and you could be too! [If you'd like more information on what we do and why we do it, click here!](https://www.reddit.com/r/TranscribersOfReddit/wiki/index)


The jdk is on GitHub now, so submit a PR and let them know this is silly.




I’m going to assume that there’s some exceptions being thrown that implement or extend (idk which) those exceptions and so to make things a bit more consistent it type casts them to those types. Still weird though.


The problem is that this code swallows some exceptions which could contain valuable information, and then throw a new exception not connected to the original one.


She problem on my font till I data


This guy knows.


*Extremely loud incorrect buzzer*




Is that a vscode theme? I really like the colors


Will never add any useful info. Might remove useful info. No logging. This is worse than useless


They potentially re-throw an OutOfMemoryError as IOException, wtf


This is the only valid criticism on this thread, handling of Errors and RuntimeExceptions. People wondering about the cast expressions miss the point of java checked exceptions.


How do you view the source code of java.awt.*


JDK is on git now I believe. (Haven’t had to touch Java in almost a decade)


Yes and also the jdk has the source bundled as a zip file, which is automatically associated with your ide So you go to your project, libraries, expand the jdk, and you can look through all of the packages and open the class files directly. You can do normal things like search, find declarations, etc but you cannot edit the source


Looks like a merge error


I'm guessing this code is expected to raise a limited number of exceptions. If so, these checks may have been added to constrain them as its internal logic became more complicated. If it were to fire off a new exception type that could create back compatibility issues.


It swallows the exception. They could still use any instance of Throwable for the cause


Not if the consuming code is explicitly catching only these two exceptions. This could break programs that are using this library.


java world in a nutshell lol


Absolutely not. This kind of error handling is a well known no-no, since it potentially hides important exception data.


It works, don't touch it.