Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jdt-dev] Use of Java asserts in ECJ
  • From: "Sankaran, Srikanth" <srikanth.sankaran@xxxxxxxxxxxxx>
  • Date: Fri, 26 Apr 2024 08:56:03 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=advantest.com; dmarc=pass action=none header.from=advantest.com; dkim=pass header.d=advantest.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uKGXcDiAeOKfd31pDSMLF/06IBH79Y8BN0rg1Pn4BKA=; b=AQZjw4LnkGMWle8N1nDrs0uMD6MhiLro8MD2CRpyX41BL6Gwv3rGV01TvfSkGhkNxsyfqYRoQOhGbN9aQzacFql88D5a8Z74DcGG8f8UiZ7kPAP2cFG+WY9DxxvRfYLmA36KS3NMqwU1chrDqS2sQI9iKYjHsV5PvlFq1Bz+VL3kqLhvJAAjsU9YKRava3Uife+rzmTRo0afW/rqUghLtEuoXvGEYb1x7Upj+f6fP5etu5rEDhV2yYLqlIqFy2MriZ94QZd8zbKCvpQKKHpQhxW8gEw84B8W+tHiyKQYqVQWxEyZC0cslk1vq6bD6njuPw61GPactTOtgO1rX8RHVA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eQH+PGqmMCWrvhsCSvSm0hUWt7KGFiLMslsrVxU8Y+g4+sxjgsFLr7cPx9XxrfaveoVriJtnlJhj9c0sTIcVr+z4FSPDiojoDIazLZiEoEDuaLvxxpnVTf4amIX6ljUdgY1PWGSf0kTY9xrZREaHWi9mySETCHlvh+0fsYSEdSXB7iTFwEStTESc8IbzmIgBnt5BEw528OvOjVXL8EFD0Z1y6m21WraMV080xdZbYrfqzN28hGFMNhHbL0EaE2Rsg2aWOH5TQuJ6UFwjg/JQT6M8eOwEX7JQD4Pp8wxl7a2/NfZxN18qH3ifP37JPOr3whmciaOV62KiiVg/SuC8Cw==
  • Delivered-to: jdt-dev@xxxxxxxxxxx
  • List-archive: <https://www.eclipse.org/mailman/private/jdt-dev/>
  • List-help: <mailto:jdt-dev-request@eclipse.org?subject=help>
  • List-subscribe: <https://www.eclipse.org/mailman/listinfo/jdt-dev>, <mailto:jdt-dev-request@eclipse.org?subject=subscribe>
  • List-unsubscribe: <https://www.eclipse.org/mailman/options/jdt-dev>, <mailto:jdt-dev-request@eclipse.org?subject=unsubscribe>
  • Thread-index: AdqSSFfU5fJAFpF7TGCmGIRrfjeuwgBxPXgAAOpOYGA=
  • Thread-topic: [jdt-dev] Use of Java asserts in ECJ

“Secondly, in the compiler we have a group of options around AbortCompilation, ProblemHandler.abortDueToInternalError() which try to report the problem as a compile error. This  has the benefit of associating the problem to a specific source location (at least the compilation unit that was currently being processed). Directly throwing AssertionError misses this opportunity.”

Thanks for calling this out Stephan, this had slipped my mind.

My repeated observations have been that github PR runs run with assertions enabled while local tests don’t.

I have manually turned on -ea for inner IDE launches. This creates another dichotomy between outer and inner IDE instances 😊

Best practice of course is not to have bugs in asserts 😊

Srikanth

 

From: jdt-dev <jdt-dev-bounces@xxxxxxxxxxx> On Behalf Of Stephan Herrmann via jdt-dev
Sent: Sunday, April 21, 2024 10:30 PM
To: jdt-dev@xxxxxxxxxxx
Cc: Stephan Herrmann <stephan.herrmann@xxxxxxxxx>
Subject: Re: [jdt-dev] Use of Java asserts in ECJ

 

CAUTION: This email was sent from outside of Advantest.

 

On 19.04.24 13:04, Sankaran, Srikanth via jdt-dev wrote:

I wholeheartedly support adding lots of sanity checks via assertions, but not via Java assert statement, but using the pattern

 

if (42 != 42) {

    throw new AssertionError("Something is fishy!");

}

 

Various situations have their specific patterns for raising red alert.

First, locally launching junit tests should always (i.e., automatically) pass -ea. If that is not the case it could be a regression vis-a-vis  https://bugs.eclipse.org/bugs/show_bug.cgi?id=479553 (or someone carelessly removed the vmarg from the launch config ;) ).

Secondly, in the compiler we have a group of options around AbortCompilation, ProblemHandler.abortDueToInternalError() which try to report the problem as a compile error. This  has the benefit of associating the problem to a specific source location (at least the compilation unit that was currently being processed). Directly throwing AssertionError misses this opportunity.

Finally, it's always a question how fatal is the problem? If, e.g., the problem occurs during indexing, should we end up with no index at all, or can we just skip some (small) part and keep going? In the IDE some problems may just be logged, and then ignored (and remember: the compiler might be called in various guises in the IDE).

Since the compiler cannot use any logging framework we can only throw, report an error or keep silent. I could still imagine situations (e.g, when reading library class with unexpected details) where the normal behavior should be "ignore", but if something fishy is observed then the assert keyword could be a useful tool. In that case we could ask a user to set -ea to figure out if any such issue was observed but ignored in normal operation.

So my simple answer would be: it depends.

But unconditionally throwing any RuntimeException or Error is a drastic thing to be done only as a last resort, if you ask me.

best,
Stephan

PS: Does anyone know, if it is possible to set -ea programmatically? In that case the ECJ Main could do just that for asserts that in other use cases could be ignorable :)

 

Back to the top