reef-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergiy Matusevych <>
Subject Re: [DISCUSS] Deprecate Exceptions.Throw?
Date Thu, 02 Jun 2016 21:08:50 GMT
I agree with Markus on this case.

Exceptions.Throw() mixes up several aspects of functionality (control flow
and logging), and Julia suggests to add even more stuff to it (statistics).

For me as a new C# API user it was not quite clear at the beginning why the
function exists in the first place.. I wondered - am I still allowed to use
the regular throw, or should I always use that function? Does the function
*always* throw or sometimes suppresses the exception? What logging level
does it use?

So, to me, it looks like a redundant and unnecessary abstraction.


On Tue, May 31, 2016 at 2:16 PM, Markus Weimer <> wrote:

> On 2016-05-31 10:16 AM, Julia Wang (QIUHE) wrote:
>> I understand most people don't like it because at this time, we
>> haven't really started to leverage logs to do something. Moving
>> forward, we will need to use log to get statics data for monitoring ,
>> diagnose, etc. Have a centralized the place would be convenient for
>> us to have a consistent logs.
> I agree with the goals. But `Exceptions.Throw` isn't the best way to get
> there. It confuses the compiler (and reader) of our code with stuff like
> ```
>   Exceptions.Throw(...);
>   return null;
> ```
> Also, `Exceptions.Throw` messes up the stack trace and leads to situations
> where we log the same Exception more than once. This is very difficult for
> us to debug, compared to the rules we adopted for the Java code. If I
> recall correctly, those are:
>   (1) Exceptions are only logged once: when caught and dealt with or
>       when crashing the process.
>   (2) Exceptions always contain a message.
>   (3) When the catch() block throws an exception in its own right, it
>       must wrap the inner exception.
>   (4) Use specific exception classes, not generic ones like `Exception`
> Details are in REEF-864.
> Those rules were made for Java. But as far as I can tell, C# supports
> Exceptions at about the same level as Java.
> What are we missing if we adhere to the above rules? How is it better
> addressed with `Exceptions.Throw()` and why is that worth the awkward code?
> Markus

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message