Suppress stack trace creation

Libraries
1

It was quite a bummer to realize that:

public open class Throwable(open val message: String?, open val cause: Throwable?)

Does not have the option to suppress stack trace creation, which is quite useful to speed things up when you know you will never use up. It’s there for a reason guys.

I tried circumventing it by subclassing java.lang.Throwable directly with @Suppress("PLATFORM_CLASS_MAPPED_TO_KOTLIN"), but then I can’t throw or catch this type anymore (according to me, that’s a bug :confused:)

A solution still, Java to the rescue:

public static class NoStackTrace extends Throwable {
    public NoStackTrace(String msg) {
        super(msg, null, false, false);
    }
}

and let your exceptions extend that (or if more motivated, you can recreate all java.lang.Throwable constructors).

(And if you even think of lecturing me on proper exception usage, sorry but I’m not listening.)

2

I think, you exaggerating situation a bit.

The reason we do not have such a constructor in Throwable that allows to suppress stack trace creation is that kotlin.Throwable is the type mapped on JVM backend to java.lang.Throwable from JDK 6, which doesn’t have such constructor either.

It’s most likely that Kotlin 1.1 will make mapped types expose all members of the platform types they are mapped to, depending on the platform targeted. It would also allow us to solve issues with Throwable like KT-5893 and KT-10887.

2 Likes
3

Sorry, didn’t mean to sound like it was an outrage. And I have a workaround, right.

But you have a pretty good reason for the behavior apparently, and it’s getting fixed.
So it’s all peachy :slight_smile:

4

My two cents: Throwables and exceptions are, as the name suggests, intended for exceptional cases - that is, not part of the regular app workload. And there is no point in optimizing code which is called only rarely. Therefore, I would really vote against such stack trace optimizations, because I believe that such optimizations promote bad programming practices.

5

Oops, it looks like you forgot to read the above :scream:
This topic sure draws preachers like flies.
(I know it’s petty, but sometimes…)

Not willing to argue this point, but non-local return does have its use.

6

Sorry, my bad - missed that particular line :smiley: Actually, I was not trying to preach, far from it (it would be hypocritic, coming from a vivid user of parseInt :slight_smile: . I just tried to protect Kotlin from including stuff which I consider harmful.