reef-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julia Wang (QIUHE)" <Qiuhe.W...@microsoft.com>
Subject RE: [DISCUSS] Deprecate Exceptions.Throw?
Date Thu, 02 Jun 2016 21:22:20 GMT
The log level is always Error as it is throwing an exception :). 

When we developed this lib, we replaced everywhere in REEF code. Although we have no way to
prevent  developers from using .Net "throw".

For the issues pointed by Markus, we can always improve it. I guess the question is do we
want to improve it or discard it. 

I can only speak for the original purpose of this lib. The value was to have a consistent
way to log error for analyzing logs in future. 

Julia

-----Original Message-----
From: Sergiy Matusevych [mailto:sergiy.matusevych@gmail.com] 
Sent: Thursday, June 2, 2016 2:09 PM
To: dev@reef.apache.org
Subject: Re: [DISCUSS] Deprecate Exceptions.Throw?

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.

Cheers,
Sergiy.



On Tue, May 31, 2016 at 2:16 PM, Markus Weimer <markus@weimo.de> 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
>
Mime
View raw message