thảo luận Best practice cho việc throw exception?

• file không tồn tại là file do người dùng/dev nhập sai đường dẫn: lỗi người dùng (error)
• ổ cứng lăn ra hỏng: lỗi hệ thống (exeception)

crazy9x256 đã nói:

Thế bây giờ findUserById, trong đó nếu theo flow thì bắt buộc id này phải tồn tại (do flow từ client truyền lên), nếu id không get được user thì nó là error hay exception ? Thím nào định nghĩa giúp mình câu trả lời với ?
Còn mình hay throw các customize exception và global handle, từ đó build các http code và error trả về client, ngoài ra dễ monitor, logging nữa ./.

Gửi từ Xiaomi MI 8 bằng vozFApp

Nhấp để mở rộng...

public async Task<Result<UserDto>> Handle(UpdateUserCommand request, CancellationToken cancellationToken)
    {

        var user = await _userRepository.FindAsync(request.Id, cancellationToken: cancellationToken);

        if (user == null) return new NotFoundResult<UserDto>("User with id {id} is not found.", request.Id);


        user.SetFullname(request.Fullname);

        _userRepository.Update(user);

        await _userRepository.SaveEntityAsync(cancellationToken);


        return new SuccessResult<UserDto>(user.ProjectTo());

    }

cookiebanana đã nói:

Cái findUserById trả về user hoặc là null, chứ không ném exception.

vd sử dụng Result pattern. Có thể tạo UserNotFoundResult để khỏi lặp lại cái lỗi thông báo.

C#:

public async Task<Result<UserDto>> Handle(UpdateUserCommand request, CancellationToken cancellationToken)
    {

        var user = await _userRepository.FindAsync(request.Id, cancellationToken: cancellationToken);

        if (user == null) return new NotFoundResult<UserDto>("User with id {id} is not found.", request.Id);


        user.SetFullname(request.Fullname);

        _userRepository.Update(user);

        await _userRepository.SaveEntityAsync(cancellationToken);


        return new SuccessResult<UserDto>(user.ProjectTo());

    }

Nhấp để mở rộng...

perepermin đã nói:

tại sao lại trả về null? k dùng exception có lợi gì đâu, toàn rãnh chế cho phức tạp ra

Nhấp để mở rộng...

bibooboo đã nói:

Exception sẽ bị middleware log là error, tạo ra 1 số lượng log vô nghĩa, tốn storage, làm giảm hiệu quả của việc tracing và thời gian của on-call team

via theNEXTvoz for iPhone

Nhấp để mở rộng...

Z_zAkiz_Z đã nói:

Xanh thì đúng rồi, nhưng cũng không cần quá chi tiết, có thể gom thành những nhóm lỗi chung kiểu DataInvalidException, AccountBussinessException, khi throw ra thì sẽ phân biệt chi tiết hơn bằng error code và message
Còn đỏ thì chưa đúng ý mình. trường hợp các exception mình định nghĩa riêng kia thì cứ throw ra như bình thường, còn các exception mà ko thuộc những cái mình định nghĩa, mình ko control được thì nên throw dạng lỗi chung

Anw, chủ đề này khá hay, cắm cọc chờ học hỏi từ cao nhân

Nhấp để mở rộng...

GeniVN đã nói:

ý em là

Java:

class UserService {
    public User getUserInfo(int id) {
        // logic
        if (...) {
             throw UserNotFoundException("user not found");
        }

    }
}

Java:

class UserHttpController {
    private UserService userService;

    @GetMapping("/users/{id}")
    public Response<User> getUser(@RequestParam int id) {
 try {
    User user = userService.getUser(id);
    return Response(Http.Ok, ...);
 } catch (UserNotFound e) {
    return Response(Http.NotFound, ...);

 } catch (Exception e) {
    return Response(Http.Internal, ...);
   }
}

}

hay là các bác dùng kiểu gì khác kiểu này để tối ưu code hơn vậy

Nhấp để mở rộng...

Each function returns a value indicating success or failure. However, with a nontrivial function call hierarchy, this approach clutters the code significantly. Every function must check the return code of every function call it makes and take care of errors. In most cases, the function will merely pass any errors back up to its caller

Nhấp để mở rộng...

perepermin đã nói:

tại sao lại trả về null? k dùng exception có lợi gì đâu, toàn rãnh chế cho phức tạp ra

Nhấp để mở rộng...

losser50cm đã nói:

Em hay làm như này. Tạo một custom exception class extend Exception class của Java, sau đó global handle trả ra client luôn như này
Xem tệp đính kèm 1986794

Hay là làm theo kiểu check if-else như này các bác
Xem tệp đính kèm 1986798

Nhấp để mở rộng...

crazymankkkk đã nói:

Mấy project mình làm qua thương sẽ custom lại Middleware để Mapping từng loại Exception vs HttpStatusCode. Trong quá trình code ko cần quan tâm quá nhiều tới HttpStatusCode này nữa lỗi thì cứ throw đúng cái Exception + Message là ok. Trước maintain dự án ko bắt dạng middleware này mà return Result(stattusCode, message). Code đúng bựa ra ngoài controller thì if else các kiểu con đà điều để mapping lại :v Xem tệp đính kèm 1998947

Nhấp để mở rộng...

venom25 đã nói:

cách này project mình cũng hay xài. cứ quăng đúng exception là có middleware catch để trả về đúng http status code tương ứng

Nhấp để mở rộng...

Lập Trình Viên Trẻ đã nói:

//Mình code C#
Mình có 1 số thắc mắc về việc throw exception trong code sau.

Bài toán đặt ra là project mình là web api, có các layer là controller => service => repository.

1. Khi validate business logic, ví dụ validate mật khẩu user sai/ đúng thì khi sai có nên throw exception không ? Nếu không throw thì sẽ viết code xử lý trường hợp sai như nào

2. Mình hay nghe senior team mình nói throw sai có thể làm lost stack trace khó debug, mình không hiểu ý này có bác nào giải thích mình với

3. Nên viết catch exception ở layer nào? Khi nào nên re-throw lại exception?

Nhấp để mở rộng...

loservoz999 đã nói:

mọi người ơi cho hỏi khi có token rồi, nếu token gửi kèm request là token đúng thì ok nhưng khi token sai hoặc không có token thì chạy vào catch nhưng không được bắt ở globalException @ControllerAdvicevà ứng dụng bị crash. Mọi người thường xử lý case này thế nào vậy

Nhấp để mở rộng...

dảk quá pepsi ơi đã nói:

Sao lại crash được bác, mặc định nó sẽ trả ra 403 mà nhỉ. Lúc này tệ nhất thì có thể để frontend tự chế message (backend mình chỉ cần trả ra 403 là được)

Nhấp để mở rộng...